[訊息論壇]ICE Messaging Forum 翁穎晰
<專訪篇>
資策會謝沃田經理 ─ 談 iPush®
Server 在水文即時監控之應用
謝沃田經理 (Marty) 是交通大學土木研究所水利組
81 級的高材生。在取得碩士學位後，先在巨廷工程顧問公司服務，6 年後加入資策會迄今。
先後參與過 Haz-Taiwan
計畫、水利局水情二期建置與更新案、921
應變中心規劃建置案...... 等重大計畫，實務經驗非常豐富，而且是少見的橫跨水利防災和資訊機電整合領域的專家。
我們透過許多努力，才為各位讀者約訪到這位水利、防災系統專家，讓大家有機會了解台灣水利防災系統的演進，以及在這個領域裡面，iPush®
Server 所能扮演的角色。以下就是本期專訪的精彩內容。
| 與資策會資訊系統實驗室謝沃田經理 (Marty) 談
iPush® Server 在水文即時監控之應用 |
記者：在一般人印象中，資策會是一個專門從事資訊服務的組織，怎麼會和水利與防災領域發生關係呢？是否請您先為大家說明一下。
Marty：你應該記得 85 年的賀伯風災吧？那次風災為中部地區和大台北地區帶來相當大的損失，事後政府檢討發現，事前對於水文情資的掌握非常不確實，而且對於豪雨所可能造成的淹水情況，也就是潛勢分析資料付之闕如，所以下定決心開始進行水利防災體系的自動化系統整合規劃與佈建。
因為如此，資策會資訊系統實驗室才開始踏入水利防災領域，當時我剛好看到資策會在招募有水利防災相關領域
know-how 的人，也正好想換跑道，才進入資策會服務的。
記者：在十年的時間中，您可算是無役不與，可否先談談您對於台灣水利防災體系自動化的看法？
Marty：以往水利單位不是很重視軟體，因為硬體廠商會免費提供。由於各個單位所需佈建的測站和資訊系統幾乎都分開招標，所以在台灣各地所佈建的水文情資測站與蒐集點有眾多廠商的產品和軟體，多年之後問題就越滾越大：
1. 廠商越多，所需要維護的系統就越來越多、越來越龐雜。
2. 由於廠商太多，整合困難，就很難有一個統一的介面進行情資的彙整與呈現，在使用上就非常不方便，而且在協助幕僚作業與指揮官下達決心上成效有限。
3. 在指揮運作上，還有很多作業程序太過繁瑣，而且依賴人工作業，在應變時往往貽誤戎機。
記者：在這方面有具體的例子可以說明嗎？
Marty：有一個現成的例子。在 89 年象神颱風時汐止淹大水，台北縣政府一直到水退了，才請到陸軍支援，其中就耗了不少時間在公文趕辦和公文旅行上。後來軍方也學乖了，在
90 年娜莉颱風來襲時，陸軍就已經把工兵的機動車輛和怪手等機械，通通移到新台五路的北二高交流道高處 Stand-by，公文則等水退之後再由北縣府補辦......
記者：咦？您怎麼知道的？
Marty：因為我家就住在汐止啊！(哈哈 ∼∼ )
記者：原來您也是災民啊，這就難怪了。
Marty：這樣子仍然會產生先前所提相同的問題，所以應變中心的規劃必須保持彈性，以便日後將其他相關系統和資訊流整合進來。
在這裡要先補充說明一下，我們現在談的防災，範圍只包括水患和風災，並不包括火災、爆炸、毒氣、疫情......
等其他災害。這些災害的防治，都是由各相關部會自行處理的。
記者：可否請您說明得再詳細一些？
Marty：好的。以水利防災來說，相關的就有水利署的水情中心、交通部的交控情資、氣象局的氣象情資、農委會水保局的坡地、土石流防治、預警......
等相關的單位、系統、與資訊流。
而在應變中心體系的規劃上，面對這麼多單位、系統、與資訊流，所涉及的整合問題大致可以分成兩個面向：
1. 橫向協調：如交通部、經濟部、農委會...... 各部會間的協調作業。
2. 縱向指揮管制：中央 / 縣市 / 鄉鎮市 應變指揮管制。
任何一個面向的整合如果出問題，就會造成整個體系的延遲與失敗。
記者：聽起來和軍方在講的
C4ISR 很像......
Marty：或許是，我不太清楚軍方的作業。
記者：這麼看起來，在您心目中應該有一個防災應變中心系統的
Framework 才對？
Marty：當然。在會內早就在進行這方面的計畫了。
記者：可否透露一些？(記者真是天生的
Spy...... 但為了讀者著想，這是一定要的啦！)
Marty：大致上可以分成資訊流和共通平台兩部分。
原則上，資訊流是由各資料提供者 (Information Provider，簡稱 IP)
負責提供和維護。涉及到的是統一的資料交換標準與資料的可取得性。這部分我們會建議使用 XML 作為資料交換標準格式，而且各部分的資料必須各有其統一的資料格式，譬如水文資訊就必須訂出統一的資料格式，而不是像先前各水文系統有各自的資料格式。
在共通平台部分，我們會採用 e-Government 的資訊系統規範，定出與防災八大系統相關的電子閘門
(Gateway)，應變中心系統則是架在共通平台上，藉由 SOAP、Web Service 等服務，透過電子閘門向各單位的原有情資系統要資料。
 |
|
圖一. 防災應變中心系統架構示意圖 |
其中最大的挑戰將來自於各單位資料來源的品質，也就是資料來源是否穩定、可靠、以及資料即時性是否能符合要求。
長遠來說，水文資料要能即時傳送到 Client 端，這是水利與防災的最終目標，但是很難達到，只能盡量逼近。
記者：
iPush® Server 恰恰是針對即時訊息傳遞、交換而設計的產品，您覺得它對於這個防災應變架構是否能有所幫助？它能扮演甚麼樣的角色呢？
Marty：就我認為，iPush®
Server 的優點在於能確實的減低網路流量、主動事件觸發、以及貴公司團隊良好的服務態度。但是如果不從資料來源端就開始用
iPush® Server 架構，那麼資料來源就無法達到即時，即使共通平台和電子閘門使用
iPush® Server，也無法完全發揮它的最大長處。所以目前我認為貴公司應該盡力爭取從來源端開始做起，才有機會搭建真正的水文即時訊息高速公路。
|
|
|
圖二. 水文即時訊息高速公路
(總覽) |
| |
|
|
|
圖三. 水文即時訊息高速公路架構示意圖 |
此外，我也希望 iPush® Server 能考慮加強對於
XML 格式資料的處理能力。目前如果資料提供者 (IP) 和資料接收者 (Information Receiver，簡稱
IR) 間先協商好 XML 格式定義，iPush® Server 可以將其當作純文字訊息流處理，沒有問題；但是如果碰到事先沒協商好的狀況，還是得靠
SI 來作 XML 資料的 Pre-processing、Post-processing。如果能有適合的工具來滿足這項需求，或許會更好。
因為 Web Service 絕對會變成主流，我希望貴公司能夠更進一步的開發 Web
Service 版的 API，這樣更方便我們使用。當然了，目前還是可以使用 Web Service 來和 iPush®
Server 進行連結與資料交換，只是如果有真正 Web Service 版的 API 會更好。
記者：這項意見我一定會帶回去給產品規劃人員，謝謝您的寶貴意見。
Marty：不客氣。其實我住在台灣的日子已經超過在香港的日子了
(我是香港僑生) ，我真的很希望能對這塊土地多盡一份心力，也謝謝你們提供這個機會讓我發抒己見。
一個國家的先進程度，不應該只是以 GDP 的多寡來評量，更重要的是國民和政府是否重視、關心未雨綢繆的基礎建設。
以防災為例，我們可以看見其他先進國家不僅有整體的系統規劃策略與短中長期政策，還有專責機構負責系統的規劃、建置、與維護 (如美國的 FEMA)。
這幾年來，台灣遭遇了無數次的風災、水災、旱災，而此刻，SARS 風暴也還未遠颺。以往國人不注重未雨綢繆，現在正是付出慘痛代價的時候。
但是，事實上還是有很多的人在默默地耕耘，希望能將台灣建設為更安全的家園，資策會謝沃田經理與艾揚科技都是極佳的例子。這些默默耕耘的人需要的不是掌聲，而是政府和民間更多的關注、更多的資源投入，讓我們共同為這塊土地繼續奉獻一己之力吧。
|
