海洋氣象數位服務專用平台之建置

李育棋1 蔡立夫1 董東璟2 陳秋份3 鄭子璉4
中央氣象局氣象預報中心1 海洋大學海洋環境資訊系2
成功大學近海水文中心3 風禹科技驗證有限公司4

摘要

  為了提供即時、正確與多樣的氣象資訊給予海上航行船隻,擴大中央氣象局服務範圍,提供船舶航行安全資訊,一套應用電腦資訊技術所建立的海洋氣象數位服務平台(Marine Weather Information Services Platform, MWISP)已經建置完成且目前正在實際推廣使用中,此平台兼具可以讓海上的船舶觀測資料回傳到中央氣象局功能。本數位平台包含四個子系統,分別為船舶子系統(SH)、網頁子系統(W3)、中控子系統(CS)以及郵件伺服器(EM)。船舶子系統是一個獨立程式,由氣象局提供船商安裝在船舶上,透過此程式,船舶可以對中央氣象局提出資料需求,並提供瀏覽資料介面,利用此系統也可以把觀測資料傳回氣象局;網頁子系統可以提供船公司或漁業電台管理人員管理使用此系統的船隻,而近海作業漁船透過漁業通訊電台值班人員的輸入,可以將海上狀況(主要是風場)傳送到氣象局;網頁子系統可以讓使用者監看與查詢回報資料並做基本統計;中控子系統則是這個數位平台的核心,它負責接收使用者所提出的需求,並自動從氣象局資料庫中編碼相關資料送達使用者,中控系統也建置了系統運作監控界面讓氣象局管理人員瞭解此數位平台的運作概況以便做必要之處理;本系統對於氣象局和外界使用者之間的溝通與資料傳遞均係透過郵件傳遞方式來運作。

  海洋氣象數位服務平台建置完成後,已經接收超過5000筆的近海漁船回報風場資料,船舶系統也已經安裝在多艘船舶上使用,整個系統已經開始正常運作超過數個月。本文將報告系統的設計,考量、功能與應用,同時也將分析目前回報資料的統計結果。

一、前言

  台灣四面環海且位處東亞航運要道,先天具有航運地理條件之優勢,隨著經濟的快速成長,台灣海運由原本提供本國貿易的運輸服務,發展成為一項提供外輪貨運服務的產業。船舶航行於海上,為使航行安全順利,應排除造成航行安全的因素,如航前有詳盡的航線規劃及航時有即時海氣象資訊,以避免船舶因地形或惡劣的海氣象象造成船隻觸礁、碰撞甚至傾覆等海難事件的發生。往昔航行於大洋的船隻係透過無線電接收中央氣象局發送的氣象預報資料,此種方式是屬於單向、定時且易受干擾,無法確認使用者的接收情形也無法從使用者端得到回應與回饋。另外,在資料接收方面,以往係透過世界氣象組織設於東京的氣象中心取得海上船舶的氣象報告資料,全世界有八個收集海洋氣象資料的氣象中心,其中東京氣象中心所接收到的海氣象資訊多為日本貨輪航行於東海、黃海、日本海及西太平洋等海域的天氣觀測報告,少有台灣周遭海域的資料,對於船隻航行台灣海峽安全的助益有限。有鑑於此,氣象局自民國95年起著手規劃建置一套海洋專用的氣象服務數位平台(Marine Weather Information Services Platform, 簡稱MWISP),這是一套資訊系統,希望透過此系統提供(provide)氣象預報資料予海上船舶,同時也能接收(receive)海上船舶的觀測資料以改善預報準確度。

  就維護航行安全的角度而言,目前在世界上廣泛地以浮標(Buoy)作為收集海氣象資料的主要工具,氣象局在台灣環島亦設置有多個海上浮標站。然而現今這些海氣象現場測站的密度遠不及海氣象預報校驗需求,為增加於海洋表面的監測數據,有許多國際計畫及公約積極為這方面做出貢獻,世界氣象組織(World Meteorology Organization, WMO)推動自願觀測艦隊計畫(Voluntary Observing Fleet Program, VOF),自願觀測船舶在船上安裝氣象觀測儀器,定時觀測並把這些觀測報告傳送到海岸基地台,亦接收氣象單位提供的最新氣象資訊,同時將觀測報告再轉送至各氣象中心以供全球交換使用。各氣象預報中心得到這些船舶報告後,配合海氣象數值預報模式,經有經驗的預報員的客觀分析,可以更準確地發布海氣象預報及警告,降低因天氣因素所導致的海難。

  本系統之目的為改進船舶的海氣象資料傳遞方式,建置一套與海上航行船舶間有關氣象資訊之傳遞、接收與顯示等氣象服務數位平台環境,利用檔案壓縮、通訊、繪圖等技術及系統管理技巧,傳送中央氣象局氣象文字、圖形、衛星照片及數值預報格網資料,透過衛星通訊或網際網路方式接收,提供中央氣象局公布之最新氣象資訊至海上航行船舶端顯示及應用,並可接收船舶端回傳的觀測資料至中央氣象局,以增加海洋表面的監測數據,以茲協助中央氣象局海氣象預報校驗使用。

二、系統架構

  海洋專用氣象服務數位平台(MWISP)分為四個子系統,各部份可獨立分離或任意部份組合於單台伺服器上,依現有的硬體數量分配調整。各子系統分別為海洋氣象服務平台船舶系統(SH)、海洋氣象服務平台網頁系統(W3)、海洋氣象服務平台中控系統(CS)及海洋氣象服務平台郵件伺服器(EM)。其說明與系統架構圖如下所示:


圖1 海洋專用氣象服務數位平台系統架構與連結 (基於安全考量網頁列示改為簡圖)

2-1 船舶子系統

  此子系統為安裝於船舶的視窗化程式,主要功能為提供船舶上人員用以申請需求及展示氣象局所提供之各項海氣象資訊並回傳所觀測到之海氣象觀測值。本系統的使用者是船公司管理人員與船舶上之操作人員。

2-2 網頁子系統

  這是一個互動式網頁,架設於中央氣象局,此子系統包含網頁程式。透過此網頁,漁業電台人員可以輸入、查詢海上作業漁船所回報的海氣象資料;船公司管理人員透過此網頁管理使用此服務之船隻,並瀏覽該公司船舶回報之海氣象資料;中央氣象局管理人員可透過本網頁進行資料管理、查詢與分析等作業。本系統的使用者為漁業電台人員、船公司管理人員及中央氣象局管理人員。

2-3 中控子系統

  此為MWISP的核心子系統,包含資料庫伺服器,負責整個系統的運作並控制各子系統間的作業,本子系統安裝於中央氣象局之伺服器。中控系統共包含多個部分,分別為收信服務、寄信服務、資料排程監控、伺服器排程監控、資料轉換與匯出匯入、伺服器監控及歷史資料維護。本子系統用以執行氣象局端各項排程、轉換等服務項目,包含電子郵件代理人收發與過濾、WMO格式的轉換、待處理郵件的偵測等。此系統為自動定時執行,由中央氣象局管理人員進行管理維護。

2-4 郵件伺服器

  本系統所有氣象局和外界之間的聯繫均是透過電子郵件的方式(包含傳送與接收資料到海上船舶),此子系統用以收發船舶或其他端之使用者寄出之信件及發送氣象服務的信件,可獨立安裝或合併安裝於伺服器上。

三、船舶接收氣象服務與觀測資料回傳子系統

  基於維護航行的船舶安全及增加海洋表面的觀測數據,摒除過去以無線電傳輸之單向、定時、易受干擾的方式,建置一套海氣象資訊雙向服務平台,可使海上航行船舶傳遞、接收與顯示的服務平台,為透過衛星通訊或網際網路方式接收,提供船舶端顯示及應用,同時接收船舶端之觀測資料回氣象局,以茲協助提供氣象局海氣象預報使用。

  船舶子系統為安裝於船舶端的視窗化程式,主要功能分述如下:

  1. 以精靈方式逐步引導使用者向氣象局提出氣象數位服務需求清單,氣象局端依工作排程寫入資料庫,開始服務本需求。船舶端使用者依需求清單介面選取所需資料範圍之地圖大小,再按此介面選項選取需求(系統訊息、文字、圖形、衛星照片與格網),最後由排程選擇資料接收的時間與間隔,寄出後即可依所設定的排程時間接收氣象局傳送的氣象資訊。圖形、文字以台灣近海及東南亞為主,衛星照片約為亞洲範圍,氣壓場、高度場及風場範圍為全球,波高範圍為東南亞,衛星照片及格網資料最大範圍會與使用者選取範圍作交集運算後送出。
  2. 圖2 船舶使用者設定資料需求之畫面

  3. 船舶端自動接收氣象局傳送的海氣象預報資料,如天氣圖、衛星照片、颱風資訊等,並可於船舶子系統的展示畫面,展示所接收的海氣象預報資料,資料的顯示具有縮放、疊圖、輪播及列印等功能,以改善圖像的清晰度且增加航行路徑之氣象研判準確度。

  4. 圖3 船舶子系統展示接收來自氣象局資料之展示範例
    (高空氣壓場與風場之套疊)


    圖4 船舶子系統展示接收來自氣象局資料之展示範例
    (衛星雲圖與颱風預測路徑之套疊)

  5. 船舶使用者將觀測資料輸入後自動回傳至氣象局,以增加海上的海氣象觀測數據,作為氣象預報模式驗証並提昇預報準確性。
  6. 圖5 船舶上輸入觀測資料回傳之畫面
    (此系統包含提供簡易輸入精靈供操作者參考)

  7. 船舶使用者提出氣象數位服務需求清單或回傳觀測資料,於輸入完成後按下寄出,子系統將資料儲存並自動帶入電子郵件之附件,可直接寄出。
  8. 船舶系統安裝簡易且不影響原本船舶航行的資訊系統。

四、網頁子系統

  網頁系統除系統管理者所需的管理、統計等頁面外,針對漁業通訊電台提供漁船觀測資料回報及查詢介面,針對船公司提供所屬船隊觀測資料回報查詢介面,氣象局預報員、值班人員及管理人員則可瀏覽所有回報觀測資訊。

  台灣四面環海,在近海進行捕撈作業的漁船甚多,長期皆以無線電向漁業通訊電台回報當時的海氣象現況,接獲回報的資料以紙本記錄,然而長時間累積的文件在儲存上較為不易,亦無法立即以電子檔案回傳予氣象局,做為氣象預報驗証使用。因此,建置一套可使漁業電台在接獲回報時,立即輸入觀測數據的網頁系統,且氣象局端可同時接收各漁業電台輸入的觀測資料,進行統計分析,可達到增加海氣象觀測資料並立即儲存於資料庫以供應用。

  漁船觀測資料回報之網頁系統主要功能為提供使用者做漁船管理及輸入回報的觀測資料,由此介面可列出漁業通訊電台所管理的船隻,可新增、編輯漁船資料或刪除漁船,在輸入回報的觀測資料方面,可利用網頁漁船資料回報之新增觀測資料輸入,為使輸入更為便捷,可於漁船回報資料查詢的地圖上大概位置直接快速點選兩次,即出現輸入觀測資料的對話框,輸入完成後立即將風標顯示於地圖上(如圖6),供漁業電台管理者再次確認其輸入值的正確性。平時觀看時將游標移至任一風標上即會顯示該資料的詳細資訊(如圖7),亦可於畫面上方的點選顯示日期,查詢特定時間內的觀測成果(如圖8)。


圖6 新增觀測資料


圖7 游標移至任一風標上自動顯示詳細資料


圖8 特定時間內的觀測資料查詢

  船舶公司所屬船隊透過安裝在船上「海洋G用氣象服務數位平台之船舶系統」回報之觀測資料,可由船公司管理人員於網頁系統查閱,並依據WMO規範之地面天氣圖標示於圖上,供預報人員參查,回報的資料亦自動匯出,供氣象局讀取分析,修正地面綜觀分析與天氣預報,如圖8所示,地圖最大範圍為全球地圖,可透過右方工具列進行圖形縮放或移動,亦可透過滑鼠直接於圖面上框選範圍格放,當滑鼠停放於圖標上,跳出較常用之天氣觀測項目表供參考。


圖9 船舶回報觀測資料

五、中控子系統

  中控系統的功能需求為郵件讀取分析、數位服務寄送、伺服器掃描、資料排程偵測、程序呼叫及歷史資料管理等,且需為自動化作業的功能,逕行由資料庫讀取參數後,全自動化自動執行,一般狀態下無需人員操控維護,僅由系統自動載入執行。實體執行檔為兩個主程序(Process),係因各程序在視窗環境下均可獨立運作,彼此互不干擾,故採一程序監控中控程式程序是否正常執行,若發生錯誤無法回應,則由程序終結中控程式;若無正常執行,則由該監控程序啟動中控程式。因此,透過此程序亦可允許網頁介面透過網路連結監控程序讀取目前中控系統狀態,下達要求重新啟動中控系統的要求,並進一步將中控系統終結而完成重新啟動。

  中控系統採用多執行緒(multi-thread)同時執行,減少資源損耗及提高集中管理。主要分成五個工作執行緒(1.郵件讀取分析、2. 數位服務寄送、3.伺服器掃描、4. 資料排程偵測、5.其他檢查),各執行緒依據資料庫內指定之間隔時間定時執行,包含時間間隔等各項預設參數可透過網頁管理介面修改。各執行緒執行時在指定間隔時間內標記該執行緒為執行中,避免同樣任務同時執行多次。

六、郵件伺服器

  基於船舶端採用郵件方式接收訊息,本系統需配合郵件伺服器進行服務。郵件伺服器可採用既有伺服器進行服務,或新建伺服器服務,基於任務單純便於管理的前提下,本系統採用獨立郵件伺服器進行服務,其功能如下:

  1. 採用標準通訊SMTP寄送郵件,並提供標準通訊POP3取得郵件。
  2. 提供一個以上郵件帳戶服務本系統。
  3. 設定寄信位置限定僅允許網頁系統及中控系統寄送,可避免濫發廣告信(mail spam)。
  4. 使用靜態IP以利透過域名寄送郵件。

七、資料庫系統

  資料庫依照資料特性分類為下列八種表格類型:

  1. 自我說明:本類型僅供瀏覽者可快速得知各資料表格的用途及欄位說明,程式中並不存取,散佈給使用者之資料表可刪除此類。此表格有助於系統管理者快速由資料庫的自我說明了解資料內容與單位。
  2. 系統設定:包含語系清單、各項參數設定。參數以字串方式儲存,數值另加轉換。
  3. 語言資料表:包含支援之兩種語系完整訊息。
  4. 事件紀錄:包含資料接收、服務排程、訊息、疑似攻擊及透過電子郵件之各項訊息予以記錄,以利後續追蹤處理。
  5. 項目清單設定:針對可接收之氣象局服務清單或觀測氣象項目清單選擇設定加以儲存。
  6. 海氣象觀測資料紀錄:將最新觀測資料寫入歷史資料表。
  7. 使用者權限:針對可接收之氣象局服務操作者及其權限儲存管理。
  8. 船舶資料:依船公司及漁會分類,包含船舶清單、信箱清單。

  在船舶端展示介面部分:船舶端基於觀測、接收等紀錄有效管理,建立檔案型之Access資料庫存取,存取檔案型Access檔並不需要安裝Microsoft Office軟體,可直接由程式存取。資料表依據前述目的分類之1~6項。

  在氣象局端管理資料庫部分:氣象局端基於管理、服務、接收等紀錄有效管理,建立網路伺服器型之SQL Server 2005資料庫存取,存取SQL Server 2005需要安裝免費的SQL Server Native Client,是一種單一動態連結程式庫,包含SQL OLEDB提供者和SQL ODBC驅動程式。資料表依據前述目的分類之1、2、3、4、5、7項。

  在氣象局端觀測資料庫部分:氣象局端基於分離船舶端回報觀測資料,建立網路伺服器型之SQL Server 2005資料庫存取。資料表依據目的分類如上述之1、6、8項。

八、所使用之資訊技術

  本系統各部分專案系統開發均採用Visual Studio 2005(VS2005)開發環境開發,VS2005使用.Net framework 2.0 (.Net 2.0)為基底,.Net 2.0可安裝在 Win9x(98/SE/Me) 及 WinNT(2k/XP/2003/Vista/2008)等作業系統之下,並相容於Windows 64 bits作業系統,WinXP SP3 、Windows 2003 SP2以後作業系統內建此環境,較舊版本的作業系統可透過線上更新 (Windows Update)或線上下載安裝。VS2005為一多程式語言、多平台之共同開發工具,並有操作介面國際化的支援,有免費 Visual Studio 2005 Express軟體可下載安裝。

  中控系統及船舶系統為視窗程式 (Window Form)平台,使用Visual Basic 2005 (VB2005)語法,並以共用原始碼方式維持兩專案系統間相關程式碼一致性,網頁系統使用ASP.NET平台,依據用途與計算量分配,伺服器端使用VB2005語法,使用者端使用DHTML、CSS、JavaScript及VBScript等語法,並使用Office Web Components (OWC)元件協助網頁繪圖與展示。資料庫採用 SQL Server 2005 標準版,資料庫備援、安裝則使用Visual Studio for Database Professionals (VSTDB)撰寫T-SQL語法,前述開發所需的語言皆可由VS2005支援,並進行偵錯執行。

  開發時所採用的作業系統可為WinXP/2003/Vista等各版本,本系統在Windows Server 2003標準版上進行開發,並配合測試所需,以Virtual Server Enterprise 2005 R2安裝多個虛擬機器進行各作業系統安裝、操作、備援及相容測試,視窗程式完成Win2k/XP/2003/Vista實機測試,網頁系統完成Win2003/Vista實機測試。

九、系統開發方法

  本系統開發時所需要的採用的規範與技術說明如下所示:

(一) 電子郵件通訊協定

  本專案在既有系統上新增數位服務功能,在大型商船、船舶上已建有電子郵件服務,故本專案可藉由此通道傳遞所需文字、圖形、音樂、影像與資料等文件。

  Internet 並不是設計用以攜帶二進制(程式和其他非文字檔案)檔案。它僅能夠傳輸傳統文字的字集(可列印的 ASCII)所製作的郵件。為了避開限制,各種語系編碼及文件編碼和其他方法因應而生。這些解決辦法全都採行相同的基本作業,文字檔採用該語系的預設字集或UTF-8字集,非可傳輸之二進制檔案,編碼成電子郵件系統可操控的 ASCII 字集。當收到郵件之後,便能夠解碼字集的字串以重建原有檔案。

  電子郵件協定在1982年公佈RFC 822後,開始統一的標準遵循。在1992年公佈RFC 1341,定義多用途網際信件延伸(MIME),此規格建議透過編碼技巧,於傳統的RFC 822信件中承載多媒體物件,例如聲音、影像及附加檔等。

  由於遠東地區採用的文字較複雜,且早期網路設備無法傳遞完整的8 bits資料,為了確保郵件能正確被送達,所以一份多媒體電子郵件中可能包含多種編碼,並造成郵件大小增加,首先在信頭 (Mail Header) 可能指定語言編碼及傳遞該封郵件的傳遞編碼,亦有可能省略,省略時無法判定預設語系,此外在收件者、標題、組織等項目上,可能採用MIME崁入編碼,先採用語系編碼後,再以QP (Quoted-Printable)或Base64編碼,編碼過的信件都將較原始信件為大,QP碼將放大信件2 ~ 4倍,Base64則放大1.33倍。信件內文則視內文狀態,若為網頁語法內文,則另包含語系編碼,若包含附加的文件,則採MIME崁入內文,若附加文件為網頁內文格式則另再包含語系編碼,最多可能高達四層內容編碼與語系編碼,如圖所示。

  當郵件在發送、轉遞時,一般使用SMTP協定傳輸,故需SMTP伺服器服務,一般SMTP均使用通訊埠25聯繫。當使用者從郵件伺服器讀取信件時,一般使用POP3協定傳輸,RFC 1225定義了郵遞事務協定(POP),RFC 1460增修定義了POP3。另外在新聞群組協定(NNTP)上,與SMTP/POP3採相同信件格式定義,Outlook Express的eml檔案及Internet Explorer 的mht檔案亦採用相容信件格式定義,最後完成讀取的郵件依據RFC1521、RFC1522的MIME規範完成解碼並取得附件檔案。


圖10 電子郵件格式與編碼

(二) 檔案壓縮與加密

  本系統平台透過衛星網路傳輸電子郵件,減少的傳輸量可有效降低通訊費用,除在信件內採用Base64編碼減少信件大小外,信件之附件傳輸前亦先行進行壓縮,以減少傳遞時所占用之位元組數。評估RFC1950、RFC1951及RFC1952等三種無失真檔壓縮和解壓縮的工業標準演算法,選擇RFC1950 ZLIB Compressed Data Specification version3.3,並採用最大壓縮參數為預設值,此格式亦受大多數解壓縮軟體支援。

  相關加密方式則採用DES配合自訂模組方式進行,由於加密會重新對檔案進行編碼擾亂,不利壓縮,若需壓縮與加密同時進行之檔案,則先進行壓縮後加密,以有效減少檔案大小,一般船舶端所發送的觀測氣象、服務需求等附加檔,檔案均小於1 kb以下,壓縮反而會因為所增加的檔頭而變大,因此只加密不壓縮。

(三) 等值線建立、縮放、平滑與加速

  等值線包含三維的座標資料,直接傳遞座標或圖檔均十分龐大,檔案大小約60 kb左右,考慮降低傳輸大小,採用數值格網檔加以傳輸,到船舶端接收後再進行建立與繪製,例如100度× 60度的範圍檔案大小不到4 kb,為原先傳輸大小的1/15左右。

  一般常用數值格網產生等值線圖,先產生正斜三角網,再計算等值線圖,在較密的等值線或格網下,將會明顯拉長產生時間。為縮短等值線圖建立時間,針對此部份進行加速,先建立空間位相陣列,並改採用最佳三角網,而最佳三角網可促進產生之等值線在各方向上有較平緩之梯度變化,並可減少銳利化的情形,但會增長演算所需時間,合併前述加速演算法後,約可增進效能近20倍。

  完成建立之等值線圖再利用加權移動平均法進行圖面的改善,避免圖形放大時等值線因張力係數出現線條分岔情形。

(四) 天氣圖編輯系統(WCE)格式轉換

  天氣編輯系統(WCE)為氣象局新一代的作業環境,輸出常用標準格式XML檔案,但由於WCE輸出之XML檔案大小過大,平均在180 kb左右,不利於透過電子郵件傳輸,因此轉換為本系統定義之wce格式進行傳輸,轉換後檔案大小約為25 kb。

  在WCE系統輸出天氣圖中,等值線、鋒面等資訊的座標點十分詳盡,但對於傳輸過程仍嫌稍多,考慮使用者在船舶端使用1440x900解析度以下之顯示器中,無法判別之點位予以略除。資料點依據不同的斜率變化量來做過率條件,規則如下:

  1. 連續三點間形成的兩線段斜率變化量小於過濾條件。
  2. 連續多點間形成的多個線段斜率累積變化量小於過濾條件。
  3. 同時滿足a、b規則之座標點移除。

  經採不同斜率變化量為過濾值繪製並於上述解析度下進行比較,斜率變化量在0.05以下無法由肉眼辨別差異,斜率變化量0.1肉眼不易辨別差異,但精細比對仍稍有差異,斜率變化量在0.2以上,已有肉眼可辨識之差異,本系統採用斜率變化量0.1為過濾條件,過濾完成後之檔案大小約為15 kb。

(五) 系統備援

  當系統上線時,應盡量減少無法服務的時間,便利使用者的需求與操作,因此本系統安裝上包含一組主系統及一組平行之備援系統。系統在氣象局可分離獨立運作安裝分為五大部分,郵件伺服器、網頁伺服器、名稱伺服器、中控系統及資料庫伺服器,這五部份均可合併安裝於同一台電腦或分離安裝在不同電腦,各子系統可選擇合併或分割安裝,但必須同為主系統或同為備援系統,主、備援兩系統間必須分割,不得合併。

  需要即時互相備援的部分為資料庫伺服器,網頁伺服器、中控系統則在安裝或維護更新時同步更新即可,名稱伺服器及郵件伺服器在安裝時完成安裝相關設定即可自動將名稱伺服器內容傳遞到備援的名稱伺服器,郵件伺服器則在名稱伺服器設定優先權來進行管理,待系統全部設定完成後進行相關測試以驗證備援伺服器是否能正確運作。

  網頁伺服器支援兩種備援模型,一是系統初始規畫在中控程式偵測到網頁伺服器連續指定次數無回應後,向名稱伺服器發出變更 www.mwisp.cwb.gov.tw 所對應的IP位置,當主系統恢復時,再向名稱伺服器發出變更對應命令,達到網頁伺服器自動備援運轉。另一為目前現況採用資訊室提供的名稱伺服器,當網頁主系統連續指定次數無回應後,自動啟動備援網頁伺服器,若主系統恢復時,自動停用備援網頁伺服器。目前設定次數5次,每次間隔5分鐘,最長30分鐘內即可完成備援轉移,主系統復原時,最長5分鐘可完成主系統轉移。

  中控系統則在備援系統偵測主系統無連續指定次數內服務時,自動啟動進行服務,至主系統恢復上線後,自動停止服務,交還主控權給主系統之中控系統,目前設定次數5次,每次間隔5分鐘,最長30分鐘內即可完成備援轉移,主系統復原時,最長5分鐘可完成主系統轉移。

  其中資料庫伺服器需要雙向備份資料,透過本系統開發的鏡像備援機制,資料庫伺服器一般即時資料鏡像可在5分鐘內完成,大量匯出入之資料則視網路及硬體處理時效逐步完成。當主機無法連線時,網頁伺服器及中控系統可自動轉移連接備援機,備援機偵測主系統無回應時,可在5分鐘內自動升等為主系統。由於資料庫通常為連續存取,因此當原先主系統完成修復後上線,原先主系統將自動轉為鏡像備援機,原先由備援機轉為主系統之伺服器不再降等,直至目前的主機無法連線時,備援機再自動升等為主系統,以此方式輪替作為主系統服務,達成相互備援鏡像的功能。

十、結論與建議

  海洋G用氣象服務數位平台已改進航行船舶的海氣象資料傳遞方式,此種方式是屬於雙向傳遞、不定時且不易受地形干擾,透過衛星通訊或網際網路方式傳送接收,船舶端可立即顯示及應用接收的海氣象資訊,氣象局端網頁亦能立即顯示回傳的觀測資料並繪製於地圖上。另外,此系統可由船公司管理者掌控所屬船舶申請的海氣象資訊,以免造成傳輸費用的浪費;航行的船隻將所處海上位置的觀測資料回傳至氣象局,增加海洋表面的監測數據,協助中央氣象局海氣象預報使用。

  本系統於今(97)年建置完成,自去年5月開始提供漁業電台使用後,截至97年7月底為止,已收集超過5000筆漁船回傳之風場資料,如圖11所示。船舶子系統在開發期間,在海上實際進行的兩個航次測試(96年9月)顯示系統運作相當良好,今年3月、4月召開數場說明會,船舶子系統開始提供船商使用後,目前已有6個船公司管理者及所屬測試船隻登錄,定期取得氣象局提供之服務。

  氣象局預報中心完成此海洋氣象數位服務專用平台的開發,在氣象局為民服務以及取得海上資料,提升氣象預報準確性的目標上往前跨了一大步,未來持續推廣使用後,成效將更將顯現。


圖11 近海作業漁船回報之海上風速資料
(2007/5~2008/7) 共5494筆

致謝

  感謝陽明海運公司在本系統建置期間提供船隻供本系統測試,陽明海運陳光治船長以及本系統說明會期間,諸多船公司與船隊管理人員提供的寶貴意見,讓本系統更加完善,作者在此表達萬分感謝。

參考文獻

  1. 交通部中央氣象局,1998/12: “氣象預報作業規範”,CWB13-WFC-OP3
  2. J. Myers, M. Rose, 1995/5: "Post Office Protocol - Version 3", RFC 1939.
  3. K. Moore, 1993/9:"MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522.
  4. K. Moore, 1996/11:"MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047.
  5. N. Borenstein, N. Freed, 1993/9: "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521.
  6. N. Freed, N. Borenstein, 1996/11: "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049.
  7. P. Deutsch, J-L. Gailly, 1996/5: “ZLIB Compressed Data Format Specification version 3.3”, RFC 1950.
  8. P. Deutsch, 1996/5:"DEFLATE Compressed Data Format Specification version 1.3", RFC 1951.
  9. P. Deutsch, 1996/5:"GZIP file format specification version 4.3", RFC 1952,.
  10. P. Hoffman, L. Masinter, J. Zawinski, 1998/7: "The mailto URL scheme", RFC 2368.
  11. R. Gellens, C. Newman, L. Lundblade, 1998/11:"POP3 Extension Mechanism", RFC 2449.
  12. World Meteorological Organization, 2007/11: "FM 92 GRIB Edition 2 - Version 4".