[訊息論壇] ICE Messaging Forum 翁穎晰
<專訪篇>
119 勤務中心系統的幕後推手 ─ 仲琦科技黃湧哲資深經理
| 在前一期週報中曾經提及，國內股票上市公司仲琦科技
(TSE:2419)，就是以人為本， 協助現代防救災與即時勤務派遣系統進展的幕後數位英雄。
憑藉整合最先進的網路與軟體技術，仲琦開創了勤務派遣系統的絕佳應用典範。
為讓讀者得以揭開 119 勤務中心系統的神秘面紗，本週報特別訪問了計畫的專案經理
── 仲琦科技黃湧哲資深經理，就讓這位 119 勤務中心系統的幕後推手，帶領我們一探究竟吧。 |
黃湧哲資深經理，119 勤務中心系統的幕後推手，除了踏實盡責，平時對於新
IT 技術的探索，也是不遺餘力 |
| |
|
圖一/圖二、全國最大的台北縣防災應變中心，也是由黃經理負責的系統整合專案
| Q：首先要請教的是，台北縣
119 建置案各期是如何區分的？是否在一開始建案時就劃分了一期、二期，還是在一期案完成後才另行建案？
|
其實每個專案都會有重點與關注的範圍，不能一開始就把範圍講得太大、太滿，讓人誤以為這個東西可以一次就達到那麼大的效益，講得很好聽，但在實際上卻達不到。當然在一開始我們就已經和業主溝通過，把要達成的目標作先期規劃。
北縣消防局在民國 89 年規劃，於 90 年建置 119 集中受理報案系統及資料庫，依防救災專屬網路 (中期建置計劃)
建置本案，並依前案的延續性做數據網路之分隊派遣系統，並整合 119 集中受理報案系統及資料庫。
整個 119 勤務中心系統作業程序可以分成四段：受理、派遣、處理、回報。其中光在受理階段，就有不少必須處理的項目：案件種類、位置研判、資源定位，以前大多必須憑經驗，現在則是可以仰賴
GIS 系統進行索引與調閱。在派遣階段，則是必須在最短的時間裡即時通知相關分隊、水電事業單位、醫療單位、警察
(拉封鎖線或交通管制)。
台北縣是台灣第一大縣，幅員廣闊、地形複雜 (有平原、城鎮、都會、山地、河川)、人口最多，而且密度分佈極為不均，複雜度相當高。所以從受理到派遣，勢必要透過網路、數據方式去做派遣決策與執行。當然傳統的電話語音下達指令仍然很重要，可以作為網路數據方式的備援。
目前派遣到抵達現場這段，未包含在二期專案範圍之內，但可望在後續第三、四期針對指揮調度進行規劃。像是車輛是否已經出動？車輛現時位置？這些資訊就會使用到
GPS 技術與即時訊息技術，讓受理、派遣調度、處理、回報這些動作一元化，而且能在最短時間內完成。
這個專案系統是用來處理救災救民的，跟生命財產關係密不可分，都是搶時間的；像火災，只要是打火弟兄都知道，delay
個三分鐘火就會迅速蔓延，如果能夠在初期就迅速出勤控制，就可以大幅降低生命財產的損失。
| Q：請您為大家解釋一下，二期主要內容有哪些，像是要解決的問題是甚麼？ |
二期專案的目標主要是通報與指揮管制間的統合一元化，包含的議題大致上有：
i. 整合中華電信之來話號碼自動顯示
(ANI) 及預留未來擴充顯示 ALI。
ii. 結合地理資訊系統 (GIS) 提供地址定位及地圖顯示，自動選取最適切之轄區分隊及相關救災資源。
iii. 運用網路監管台監控各分隊系統連線狀態，以利管制人員瞭解系統連線情形，有效掌控各分隊勤務運作。
iv. 救災救護指揮中心與災害應變中心資訊傳遞系統整合。
v. 藉由數據網路執行各分隊同步化派遣、語音廣播及列印派遣令。
vi. 提供各分隊消防車輛、器材裝備及人事基本相關資料之維護更新介面 (可由業務單位及各分隊/大隊端依權限執行新增、刪除、修改、資料自動彙整等)，使救災救護指揮中心戰力資料庫常保最新資訊，以利救災指揮調度。
圖三、台北縣消防局勤務中心案件受理派遣系統畫面
|
Q：再麻煩您深入剖析一下主要架構與所使用的技術好嗎？ |
好的。二期專案所採用的系統架構可以看這張圖比較清楚：
圖四、二期專案系統方塊圖
1. 受理派遣系統及指揮監督系統。位於 119 勤務中心，採取
Client/Server 架構
2. 分隊案件處理系統及災害應變中心之資訊系統。採取
Web-based 架構，災害應變中心與各分隊透過網際網路和勤務中心連結，將接收資訊集中管理、系統易於維護之效。
3. 未來將加入車輛行動監控系統，以利 119 指揮及調度。
4. 有關受理台、監督台、分隊台及應變中心之相關訊息傳送，是以即時訊息伺服
器，也就是 iPush® Server 為核心，各點之間訊息即時流動，剔除訊息傳遞延誤
的問題。
至於 iPush® Server，在裡面扮演的是訊息伺服器的角色，負責三件事：
其中關於 ANI / (ALI) 的部分，目前除了台北、桃園兩縣外，全台灣都已經作到了 ALI。主要原因還是出在成本，因為這項服務是由中華電信提供，設備和
ISDN 線路必須向中華電信申請，租金並不便宜。我們也和主任談過這個服務的重要性，如果有更充足的資訊能餵給系統，就可以協助中心人員作出更快速、確實的決策，節省更多寶貴的時間。
舉個例子：中心人員接獲通報案件發生在萬里鄉某條路上，可是中心人員並不見得知道萬里鄉有個甚麼路，雖然系統可以告訴你有哪些路，但還是需要人去下令搜尋。如果有了
ALI 服務，一下子就可以把報案地點定位出來，再配合系統的 GIS，就可以把相關的資源全部定位顯示出來，中心人員作決策判斷就可以更快、更準確了。
目前利用手機報案的已經有三到四成，將來還可能攀升，未來行動通訊的定位服務資訊也會是一個重要的議題，不過這得和各系統業者配合才成，因為各系統業者所使用的定位技術都不大一樣；但這絕對是趨勢。
接著說受理派遣系統：負責案件受理、資源定位指派、下達派遣令至各分隊。日後行動監控，了解後續指揮調度，像車輛位置、災害現場資訊
(包括語音、影像直播) 以進行更進階的判斷與稽核管控。這些要靠 IT、通信、影像技術的整合運用才可能達成。
受理派遣在中心端採用 Client/Server 架構，其他像災害應變中心與各分隊，則是採用
Web-based 架構，透過 iPush® Server 與中心連接，即時交換訊息。
主要功能目標有二：一是受理並同步列印派遣令；一是語音警報廣播。
派遣令內容包括災害種類、地點、時間、GIS 地圖 (包括街道、巷弄分布、消防栓位置、數量與狀態)。拿著派遣令前往現場，可以事先了解消防栓位置、行進路線，便於作戰兵力的開展與調配。
圖五、分隊受理派遣指揮系統畫面
對。所以這是現場調度非常重要的依據。未來搭配行動監控，現場指揮官可以用
PDA、Tablet PC，知道其他部隊的兵力、位置、狀況，就可以馬上與其他部隊進行指揮或協調聯繫，不讓全部兵力一股腦往前瞎衝，而是可以先適當調度兵力配置。這個以後也會用到
iPush® Server 的即時傳訊功能，進行多點間的協調運作。
|
Q：將來二期完成上線運轉之後，您預期能達到哪些成效？ |
就我認為，二期專案預期要達成的功效計有：
1. 運用地理資訊系統 (GIS) 功能輔助災害搶救、緊急救護等勤務派遣，達成迅速、正確完成人命救助工作，減少災害損失。
2. 有效執行勤務作為，使受理報案、派遣、管制、決策、指揮機制一元化，避免非必要之行政程序延誤，導致災情擴大。
3. 建構本局及所屬單位消防業務資訊化，使災害預防、搶救、緊急救護、教育訓練、行政、人事等工作發揮最佳管理效率。
另外，二期並不是本專案的終止，下一期專案將以車輛行動即時監控為主，並整合目前集中受理及即時派遣，以達到全面
119 受理、派遣、指揮及調度一元化。
|
Q：在這個案子裡面為何用 iPush® Server？在使用上有何特別之處？ |
像過去較早的新竹案子沒用到 iPush® Server，而是利用一些
Socket 元件自己進行程式設計，常發生一些網路連線與傳輸的問題，不易控制、不穩定、不好管理，尤其在連接點數量多的時候更嚴重，而且也沒做到
Store-and-Forward (編按：台北縣 119 建置案，使用的是 iPush®
Server V2)。
使用 iPush®
Server，最主要的就是能夠在時效上達到一個全面的效益；iPush® Server
所耗用的網路資源真的少很多，是非常重要的底層訊息交換與傳遞技術，這也是我們 (仲琦) 比較 Preferred 的。在訊息流的管理技術方面，我們並不像艾揚這麼擅長，所以必然要透過艾揚的
iPush® Server 訊息平台來作為訊息伺服器，我們則是在應用程式裡面使用
iPush® API，完成雙向、即時、多點的訊息傳遞任務。
另外，過去台灣在水平、垂直方向的訊息傳遞與協調上，很多問題都在九二一之後浮現出來，就我們的角度來看，iPush®
Server 就能提供很適切的解決之道。有這樣的平台，我們可以不去管底層訊息流的技術層面，只要知道要從哪裡送到哪裡、傳甚麼東西就可以了。而且，iPush®
Server 傳遞訊息速度夠快，而我們最看重的就是時效。當然在電信方面也是要做到這樣，尤其通信絕對不能有死角，不過這又涉及更多因素，像是電信線路、交換機等。
像各分隊是利用預錄語音檔案，由中心發出訊息啟動檔案播放。勤務中心這邊則是利用電信的 Text-to-Speech
技術通知局內各相關單位。像在呼叫各單位進駐應變中心，或是群呼各單位前往現場支援時，Text-to-Speech 技術可以節省大量的撥號與語音溝通時間。
|
Q：分隊那邊為何不用 Text-to-Speech？ |
因為那要透過 PBX，而各分隊 PBX 是封閉性的東西，無從整合起，中心用的是比較標準的交換機，就有些標準的 Protocol
可以使用來控制。
|
Q：所以如果全部換裝，就可以用 Text-to-Speech，但是 Data 部份還是得用iPush®
Server？ |
沒錯。
首先，人不一定都在 PC 前 (可能在附近)，必須以音響訊號才能引起注意。其次，警報音訊可以不只一種，火災用一種
(哦依哦依~~)，其他的狀況則使用其他的音訊，一聽到警報音訊 (哦依哦依~~)，人員就先著裝搶時間，一拿到派遣令就可以馬上出發。
目前沒有什麼太大問題，其實每個分隊辦公室都不大，隊員也都在附近，如果有警報，就會有人利用播音設備發佈。台北縣有
60 多個分隊，狀況都不太相同。但我認為這些都可以日後一步一步加進去。
就像開宗明義所提到的，一個專案一定要有焦點，先把焦點的部份做好，日後再依據使用經驗和新的技術情報加入新一期的功能規劃方向。
目前大概都可以滿足。
還沒正式測試，目前只完成教育訓練，要到測試之後才能確切的結論。其實過去利用電話語音也不見得慢，但是本系統可以確實地減輕中心人員勤務負荷。
基本上系統己經可以完全滿足規劃的需求，但還是需要各分隊值機人員的配合。人的因素只能透過行政命令督導還有不斷的訓練來解決。
此外，本系統也可以維持平常業務受理派遣的記錄，解除勤務中心和各分隊的困擾。只要適當地設計與使用，系統效益自然就會彰顯出來。
系統本身也必須簡單化、易用，才能吸引消防人員使用。尤其台北縣消防人力嚴重短缺，平均每人須服務民眾數達到
500 至 600 人，國外平均也不過 100。詳細數字必須再 Check，但確定的是，台北縣消防人力短缺情形是全台灣最嚴重的。
所以日後類似消防檢查之類的輔助系統也會進行規劃，以減輕人員負擔。這些並不屬於 119 勤務中心系統，但是如果能整合就更好。
比如，高樓救火可能會用到建物平面圖 (乙種防衛圖)，消防檢查系統裡如能直接提供是最完美不過的。
註：甲種防衛圖指建物外的地形地物圖，乙種防衛圖則是建物內的建物平面圖。
|
Q：冒昧請教一下本專案時程的切割、所需動用的人力？ |
因為對需求熟，系統設計就快，而且 Socket 相關部分就用
iPush® Server 作掉，省了很多事。其實就是在系統規劃分析階段要把訊息流規劃好，像相關的
tree、action、channel、message consumer、message provider 等等。
專案所動用的人力，計有一位 PM 兼 SA/SD，三位
Programmer。專案時程則可依訪談 (14)、需求分析
(7)、系統分析 (7)、系統設計 (14)、程式撰寫 (38)、整合測試 (6)、教育訓練 (4)、上線輔導 (5)及系統轉移
(5)計算，約 100日曆天完成。
已經完成人員教育訓練，目前正在進行最後的一些調整，預計 11 月中下旬驗收，12 月底後全面上線運作。
|
Q：所以台北縣民在 12 月底之後就能享受這樣的服務了？ |
沒錯。專案進行得很快，大概一百個日曆天就完成了。其他支援性的次系統，像人事資源、車輛、器材管理系統也在這次整合進來，讓中心可以得知人、車、器材等戰力資源最新的出缺勤狀況。
圖六、派遣令下達
─－ 出動了！
我認為，iPush® Server 在這個專案裡最重要的價值所在，就在於主動提供訊息給受理人作為決策判斷的依據，並讓中心、分隊與應變中心間的訊息交換，由「接近」即時進步到「即時」。雖然乍看好似小小的一步，對於不熟悉網路程式的人卻是極大的一步。
