[訊息論壇]ICE
Messaging Forum 翁穎晰
<應用篇> Rich
Content, Simple Messaging ─ 水資源管理
台灣雖為降雨豐沛地區，年計平均雨量達 2,500 公釐，惟因時空分佈不均，年利用量僅為總量之 22％；故每人每年平均分配雨量與年計平均降雨量幾不成比例，水源供給量已明顯不足，水資源開發與調配日趨重要。
鑑於台灣地區都會生活圈之形成與城鄉發展差距的縮減，水資源的規劃方向，勢必由傳統的流域性規劃，邁入區域性的水資源整體聯合調配規劃。
水資源管理系統所涵蓋的範圍，由水文資料的蒐集開始，蒐集好的資料作為統計分析與預測、模擬的基礎，同時也是水資源調度管理與水文資訊異常警示的根據。其中統計分析、調度管理、以及異常警示，卻有著截然不同的訊息傳遞交換需求。
統計分析要的是良好的採樣結果與歷史資料記錄儲存，而調度管理與異常警示則是著重於對突發事件的即時反應速度。以往要同時滿足兩方面的需求，根本就是不可能的事，只能提供妥協性的解決方式，或者將兩種需求各自成案，分開規劃建置。
這對於我們來說，實在是很不可思議的事；因為艾揚作為提供即時訊息傳遞平台的技術原廠，深知只要將資料流向定義清楚，利用 iPush® Server
所建構的通用訊息平台，就可以同時滿足這兩方面的需求。
以往的水資源規劃方式，著眼在於單一水系的流域性規劃，而且同一水系上不同的水資源設施 (如水庫、攔河堰等蓄水設施、灌溉大圳控制閘門、…)
所採用的管理調度系統，係各自獨立招標建置，甚至水文資訊採集設備與資訊處理系統也是分開招標，由不同廠商採用不同解決方案建置的情況，比比皆是。
此外，針對不同目的所建置的系統 (如攔河堰的營運操作系統和逕流測報系統) 所需的資訊、採樣頻率、和傳輸延遲限制不同，資料格式也不一樣。
無論是以機電整合，或是以資訊系統整合的角度來看，這都是一個充滿異質系統的環境，如今要轉變成以區域角度進行規劃與調度，首先要面臨的，就是如何整合的議題。
目前實務上的作法，仍是以資料庫作為數據交換的中心，如下圖所示：
|
 |
| |
|
圖 1. 以資料庫為中心
(DB-centric) 的水資源管理示意圖。 |
圖中左右兩個曲線區塊，分別代表由兩家不同廠商分別於不同時期所建置的系統，左邊區塊較右邊區塊先建置。B 廠商在進行右邊區塊的規劃時，必須擷取來自左邊區塊的水文資訊，而這些資訊都放在由
A 廠商業已建置的水文資料庫中。
在考慮設備傳輸資料格式，以及盡量不要影響現有系統等因素之下，通常 B 廠商會另行建置一個水文資料庫，再以定時整批複製的方式，由原有之水文資料庫撈取資料，以供右側監控中心的控制台應用系統使用，而監控中心控制台則是以定時
Query 的方式，向水文資料庫擷取新資料。這樣的異質系統整合方式並非特例，而是業界的普遍現象。
這樣的整合方式，看似滿足了提供統計分析數據，以及突發性水文異常預警與調控兩種需求，但其實是在兩種需求間尋求妥協。這樣的妥協方式會產生幾個問題：
1. 傳輸延遲的增加
假設第一筆測站紀錄是在 10:01 am 寫入水文資料庫，而前端每五分鐘定時向資料庫查詢資料，前一次查詢時間是
10:00 am，那麼要能抓到 10:01 am 這筆紀錄只有在 10:05 am 再次查詢時，才會出現在前端使用者面前。在實務上，這不會影響統計分析與預測作業的精確度，但是對於突發性水文異常預警與調控，卻是值得商榷的。
2. 網路與資料庫流量增大
傳統方式係採用定時向資料庫主機查詢資料，一旦前端使用人數增加，網路流量會隨之大增，資料庫的負擔也會因為查詢動作的增加而加重，效能為之銳減。
3. 資料庫資料定時複製 ─ 雪上加霜
尤其是在測站資料蒐集和水資源管理系統分別由不同廠商建置的情況下，還會多出一個資料庫資料定時複製傳輸的動作。在此期間，使用者幾乎無法從資料庫要求查詢。如此不僅會再增加資訊傳輸延遲的時間，更會定時加重網路
(兩個資料庫間) 流量和資料庫本身的工作負擔。
4. 系統擴充性差
由於前端使用者數目和接收處理設備數量必須有所限制，甚至資料的傳輸頻率也必須限制，因而侷限了系統的擴充能力。
或許可以這麼說：在以往的技術限制下，目前所採取的方式已經是合理的架構。不過，隨著新技術的演進，要達到最佳化有更好的解決辦法 ─ 採用
iPush® Server 建構通用訊息平台，讓資料庫專責執行其最出色的任務 ─ 儲存資料，充分發揮其該有的效能。
iPush® Server 本身具備 Content-independent 的特性，因此無論資料來源是文字檔、二進位檔、字串、或是資料庫欄位，iPush® Server
都可以執行即時訊息傳遞的任務。其架構是：
< N 種資訊來源>－<通用傳送機制>－< M
種接收端>
以下圖為例，資訊來源就是各水位 / 雨量測站、水庫、抽水站 / 水門管理站，由現有監測儀器接收的水文訊息，中間架設 iPush® Server
作為通用的訊息傳遞平台，接收端則是監控中心的監控台，水文資料庫則是同時為資訊來源和接收端。
|
|
| |
|
圖 2. 以訊息中介軟體為中心
(MOM-centric) 的水資源管理示意圖。 |
由各現地測站或管理中心所測蒐的資料，會源源不斷的透過 iPush® Server
送達水文資料庫進行寫錄動作，確保統計分析預測所需歷史紀錄儲存無虞；客戶端不再定時向資料庫要求查詢，而是直接接收由各測站透過 iPush® Server
主動遞送過來的資料，只有在需要進行統計分析作業時，才向資料庫要求查詢。
這樣的做法有幾項優點：
1. 水文資料庫間不必定時進行資料複製，接收端也不必定時向資料庫查詢資料，可有效減輕資料庫的負擔，提升原有系統的效能。
2. 因為不必再定時向資料庫查詢資料，讓相同資料重複出現在網路上的機率降至最低，網路頻寬的利用可達最佳化。
3. 讓水文資料庫專心滿足統計分析需求，即時性水資源營運與預警需求則是由
iPush® Server 給予充分的滿足，徹底達到最佳化。
除此之外，以 iPush® Server 作為通用訊息平台，也為系統保留了最大的擴充彈性。其原因為：
1. iPush® Server
採用 Pub / Sub 方式收送資料給接收端，資料流則是以頻道
(Channel) 進行規範，接收端只要訂閱相關的頻道，就可以收到某測站的某種水文資訊。所以要添加接收端數目並不困難，只需做好使用者權限管理工作即可。
2. iPush® Server
提供 C/C++、Java、… 等各式 API 可供接收端使用，接收端設備不侷限於 PC，各式具備行動通訊能力的 Pocket PC、Java
Phone 都可以是接收端。監控中心也不會被限制在一個固定的場所，而是進化、提升為行動監控中心，可因應突發狀況隨時隨地不中斷的運作。
3. 只要具備
TCP/IP 連網能力的測站設備，都有辦法變成通用訊息平台架構中的資訊源。只要規劃、設定好該資訊源所需的發布頻道，資訊源的擴充就成為理所當然的事情，而不是舊有架構中的問題。
以上的架構，不僅適用於區域水情監控中心與現地測站之間的訊息傳遞，如以 Cluster 的叢集方式，將各區域水情監控中心連接起來，更可以打造一個跨區域的水情監控網絡，如下圖所示：
|
|
| |
|
圖 3. 以訊息中介軟體架構起來的即時、遠距、多點水資源管理示意圖。 |
此時，由各級 iPush® Server 所建構的 Cluster，扮演的正是訊息高速公路的角色；水利署級水情監控中心可以透過底下各層級的
iPush® Server，收到各現場測站所發送的即時水文資料，掌握第一手的水資源狀況，而不是透過由下級機構所傳遞的過時報表資料去掌握水資源情報。
同時，這樣的架構也讓水利署可以延用行動監控中心的概念，讓全國水資源的監控中心能夠在任何時地開設 ─ 即使是在立法院。
| Rich Content, Simple Messaging |
前面所談的水資源通用訊息平台架構，其實正是「一個訊息，同一時間，可以傳送給不同設備、不同使用者的不同加值應用接收」概念
(參見第
19 期「Rich Content, Simple Messaging」一文) 的體現。
事實上，我們往往可以在環境監控和防災領域裡找到相同的境況：因應不同需求所開發建置的應用系統，最後還是被要求資料流要能分享、要能整合起來，還要能因應即時性的需求。
以往多種重複的資料源流，最後終將走向統合的道路，以同一種資訊，在同一時間傳給不同設備、不同使用者，以不同的方式進行資料處理與呈現。
水資源即時調控與管理祇不過是其中一個例子而已。更重要的是：這已經不只是一種技術的變革而已，更是應用與工程設計、執行觀念上的革命與潮流。
在環境監控和防災領域裡，時間永遠都不夠 ─ 2003 年 SARS 風暴已經做了最完美的詮釋。
在這些領域裡面，如何累積有用的知識和建立高效率的預警/指揮管制體系，是同樣重要的。由於對災害的知識不夠，所以需要藉由統計分析工具，進行歸納、整理的工作；對於建立高效率的預警
/ 指揮管制體系，由於受限於技術與法令，還有很大的進步空間。
在屢次對抗自然災害 (風災、水災、疫情) 的經驗中，我們驀然發現：預警不夠即時、指揮與管制不夠落實。如何縮短預警時間、降低指揮管制訊息傳遞延遲與漏接，都應該是這個階段最重要的思考和執行方向。
我們相信，「一個訊息，同一時間，可以傳送給不同設備、不同使用者的不同加值應用接收」的「通用性訊息平台」概念，一定可以，也一定會在其中扮演極為重要的角色。
|
