[訊息論壇]ICE Messaging Forum 翁穎晰
<專訪篇> 推動警務 / 消防 / 救護勤務邁向即時時代
─ 專訪仲琦科技
| 在艾揚科技拓展即時訊息傳遞平台的過程當中，我們找到許多也在致力追求，邁向即時訊息時代的合作伙夥伴，仲琦科技便是其中之一。
受訪者林開輝先生是仲琦科技的資深經理，典型的青年才俊，畢業於中正理工學院測量工程學系；其後負笈英國愛丁堡大學，取得地理資訊系統碩士學位，並榮獲
1994 年愛丁堡大學傑出論文獎。 |
 |
| 林開輝資深經理從學生時代就與 GIS 密不可分，曾參與許多重要專案，包括規劃 AutoCAD 配合電腦製圖作業、研擬各式地圖電腦製圖之標準作業流程
(SOP) 及標準檢核流程，並參與消防署消防系統規劃、以及海巡部營控中心軟體規劃執行等工作。
由於他的慧眼明辨，將艾揚 iPush® Server 導入仲琦的許多警務
/ 消防 / 救護系統專案當中，也因此奠定雙方良好的合作關係，可說是艾揚在 M2M 領域堅實的合作夥伴。 |
| 問：
首先要請教一下仲琦在警務 / 消防 / 救護業務的發展歷程與概況。 |
答：仲琦在業界是以系統整合 (SI)
的角色自居，只要 user 提出需求，我們都有能力去滿足他的需求。我們的服務內容涵蓋層面相當的廣泛，包含資訊、通訊、網路技術在內，甚至是硬體方面，例如工業設計、機械設計、電路設計、自動控制方面，仲琦有能力將上述這些元件應用不同的
interface 整合起來，customized 之後，實際符合客戶的需求，提供 total solution 給我們的客戶。前提是以地理資訊系統
(GIS) 作為我們的核心技術，扮演 total solution 核心的角色。近年來國內剛好不斷的有各種災害情況發生，所以在警政、消防、與防災體系上，就有較為充裕的經費來進行資訊系統的建置，進而改善防災救難的效率。仲琦一開始是由新竹縣的
119 勤務派遣系統開始，獲得委託單位的信賴，之後也接下了台北縣消防局的勤務派遣系統。
| 問：
日前甫發生蘆洲大火慘劇，我們從報章雜誌上所能瞭解到的情節當中，據稱消防車隊在十分鐘之內已經趕抵現場，但是遭逢巷弄狹窄無法順利救援。請問仲琦的即時監控與派遣系統可以提供哪些改進之道？是否能夠再提升消防系統的反應速度與消防車隊的即時調度效率？ |
答：新的系統可以縮短新進人員與資深人員之間經驗的時間差異，但並不會破壞原本的作業流程，而是提供新的工具讓救難人員快速的實施救援工作，以
119 的作業流程而言，報案電話打進來時，即可辦別其所在地址，接著系統會列印出勤務內容，將派遣令交付分隊，派遣令中提供了事故發生的地圖，另外，水源也是重要的資訊，在系統裏預先輸入相關消防救災的資訊，包含消防栓、消防砂、蓄水池的所在地等等，讓救援工作能更順利的進行。
以這次的蘆洲大火而言，消防車到達現場才發現巷弄太窄無法進入，而最近的消防栓又距離
100 公尺之遠，讓救援的工作難度增加，蘆洲大火讓消防單位重新思考是否需要建立更細部的地理資訊系統資料。圖資的精細程度，牽涉到投入的成本，目前只能提供
1/1000 到 1/5000 的地圖資料，道路資料就是一條線，並沒有細部的巷弄資料，真要做的話，投入成本相當的高，是否符合經濟效益，是值得考量的因素。資訊系統一開始如果就提供十分詳細的巷弄資料，可能必須要每季或每月派人去做現地調查，加上這類的資料十分的動態，調查完現場資料必須將資料回傳，納入地理資訊系統，做為勤務派遣時的參考依據。
在我的看法裏，就算投入大量人力物力的成本，也不見得會有實際的成效出現，因為每天隨時都會有人搭建違章建築，資料隨時處於動態的狀況，也許前一周才剛更新的資料，到了現場，仍舊發生消防車遭到阻隔，無法深入火場救火的情形。況且資料的更新光以消防隊的人力而言，是不可行的，若考慮由鄰里長來負責這些工作，就專業圖資資料的提供而言，並不可行，因為不具專業知識，絕對不是在電話上口頭報告就可以表達清楚的，而且鄰里長也沒有責任要負責這項工作，這牽涉到民政業務的規範，茲事體大，在實際執行上，有其窒礙難行之處。
| 問：
在現有的警務 / 消防 / 救護即時監控與派遣系統當中，標準作業流程 (SOP)是否已經完備？依據現行的標準，數位化的監控是否會遭遇到使用者介面的阻礙，造成新系統導入的困難？ |
答：理論上勤務派遣系統的主要流程
SOP 應該都一樣，但事實上由於各地方政府的流程在細節的處理上各有異同，台北縣災害應變中心的案子因為必須與 119
報案系統連接，所以我們也順利的承接下來，將整體的資訊服務系統規模放大到地方級首長的災害應變系統，而不單純只是 119
報案受理指揮派遣而己，其己經全面升級到防災應變系統的構面。119 的勤務派遣是 365 天，一天 24 小時，不斷在進行中的，而災害應變中心的層級較高，資訊系統的內部資料會不斷地更新，但是否針對個案成立緊急應變小組，還是需要地方首長下令，才會開始啟動運作。
目前各級地方政府皆具備由中央制定的 SOP，或許在細節上不盡相同，但是大致上的流程並無二致。人並不是系統運作的問題，系統的資訊內容充裕與否，以及訊息傳輸的速度，才是作業流程是否快速順暢的關鍵因素。
圖
1、目前國內防救災體系架構 (來源：內政部消防署)
| 問：
GIS 在目前警務 / 消防 / 救護即時監控與派遣作業當中，扮演何種角色？ |
答：GIS
系統，從一開始受理報案時，就可以即刻提供報案地點的地理資訊，接下來的派遣工作也因為掌握了確切的地理位置資訊，讓救援的工作更加確實而有效率，如指出水源地等。未來也可以做出最佳路徑的規劃，讓救援工作有效執行，而附近的警察單位也可以就近進行交通管制的工作。
另外，在受理報案的同時，立刻辨別火災地點所屬的轄區單位，發送義消人員的簡訊通知，在最短的時間內召集人員，投入救災工作，不必再一通通電話慢慢撥出去，既耗時費力又不具效率，而相關的醫療院所也可以陸續派遣救護人員，前往事故現場展開救援工作，將醫療資源做最好的配置，舉例來說，火災時的燒燙傷救治單位的資料十分重要，病人要送到有病床、有相關救治設備的醫療院所，否則到院後又必須轉送，不但耽誤了救援時間，可能讓病患在轉院途中喪命，更浪費緊急救援的人力，十分不經濟。
以目前狀況而言，各縣市分別處理消防救災的工作，當遇到跨縣市的救援工作時，就無法做整體救援行動相關資源的配置，像是無法掌握醫院病床數、救援人力的數量等等，這必須提昇至中央消防署的層級來考量，以火災而言，是點的救援，比較少動用到跨縣市的資源，但像是
SARS 這類的重大疾病防治，就屬於全國性的，中央必須成立災害應變中心，來統籌指揮救援的相關措施。成立災害應變中心的層級分為三個，分別是鄉鎮、縣市、和中央，當有重大災害發生時，就由中央成立災砉應變中心，來統合調度所有的資源。
| 問：
在強調「行動化」數位系統的時代當中，仲琦是否已經具備多樣化平台支援的能力？請簡述目前在「行動通訊」上的新發展與應用概況。 |
答：在行動化的規劃上，仲琦算是有比較完整的支援，因為仲琦還有通訊事業部，未來在這個部分，仲琦會有比較大的著墨空間，因為在將來，許多外部的活動體，會透過無線裝置進到內部的控制端，以消防系統來說，必須做到所謂的多重備援，像是重大災難時，GPS、GSM、甚至是未來的
3G 都可能要納入，另外像是衛星電話、警用頻道的無線電等等，都可能規劃到通訊系統的這一端，這部分對仲琦而言，我們是有足夠的能力去
cover 這些技術。
至於後端的資訊部分，我們本來就在做了，所以在整個業界而言，仲琦算是最有技術能量的廠商。以
GPS 而言，最早是用在測量，我們很早就在做了，近年來在汽車導航上比較蓬勃發展，精度可以掌握在 5 公尺附近，效果相當不錯。目前應用車機的管理上，包含
GPS 模組、通訊模組、以及小小的 LED，顯示出簡單的命令內容，屬於單向的指令下達。未來將搭配工業級的
PC，讓所有資訊更加完整，除了知道本身位置之外，還包括其他車機的位置，如此才能達到協同作業的程度，並且透過 iPush®
Server 去區隔資訊的流向，讓所有授權的資訊充分揭示，達到管理上的效能。由於 Notebook 在防震、防高溫、防水上的問題，都必須克服，人機介面則必須採用
touch panel 來進行控制，所以工業級的 PC 是必須的配備。
| 問：
原有使用 Client-Server 架構是否足以應付追求速度的即時監控派遣系統？
導入 iPush® Server 之後，仲琦在警務/消防/救護應用當中，獲得哪些重要的競爭利基？ |
答：目前在做警政消防的廠商並不多，我們也不提是哪幾家了，他們傳統就是以
TCP/IP、socket 方式來做資料的傳輸，在初時資料少或連接點少的情況下， 大致上是 OK 的，並沒有太大的問題。但是一旦資料量增加，連接點一多之後，資料塞車，造成傳輸瓶頸等問題，便會一一浮現，而別的廠商卻沒有及早意識到這個問題的重要性
。
仲琦在仔細考慮底層的平台需求之後，以系統整合廠商的角度出發，找到了艾揚的
iPush® Server，在多點、資料量大的情形下，用 Middleware 的方式，去做資訊量的控制，才能達到即時傳輸的效果。以前的資訊慢歸慢，還是可以傳送得到，但是在即時的要求上就無法做到，一旦碰上消災救災的工作，傳統做法上即時性的缺陷就立刻顯露無遺。
其他像是油罐車派遣或是其他的物流系統，對於時間的要求並不嚴謹，可以在三、五分鐘或是更久的時間內，更新資訊就可以了，這樣所謂的即時訊息平台就沒有存在的價值，但在處理警政、消防的相關任務時，即時的要求就十分重要，強調的是幾秒鐘以內的應變，這時候即時訊息傳輸就十分重要。
以警務/消防/救護系統來說，訊息更新的需求，以
3 秒鐘為臨界值，超過 3 秒鐘幾乎就是無法容忍了。以救火來說，相差 3 秒會造成什麼損失，坦白講，無法量化，但是資料一慢，後端處理的人必定會慌亂，以車機系統來說，車子移動的變化量就十分重要，而監控數據就更有意義了，讓相關單位可以據此發佈相關的警訊等等，搭配到這個平台，最主要的考量就是即時性。
| 問：
為因應災害發生，相關電力、天然氣等維生管線的資訊是否納入地理資訊系統之中？ |
答：對於維生管線的控制而言，是和消災工作密不可分的重要關鍵。目前維生管路的分工，各有其所屬的業管單位，必須由消防單位採取通報的方式，通知其所屬的單位儘快前進事故現場處理，以蘆洲大火為例，消防單位立刻通知電力公司、瓦斯公司切斷電力和天然氣的供應，以利救災工作的進行，並且避免造成更大的生命財產損失。
這中間有個問題，災防單位有相關的緊急派遣資訊系統，而其他單位沒有，所以他們到達現場的時間勢必會比較慢，沒辦法達到一致的迅速，未來是否將相關的電力、瓦斯管線資料納入資訊系統當中，在接獲通報的同時，就告知要前往什麼地點去進行斷電等工作
，是一個可以思考的方向，不過現階段並沒有做到將公共管線資訊納入資訊系統的程度。這當中牽涉到政府和民間機構的溝通協調問題，比單純的資訊系統要複雜許多，並不容易解決
，而且電力、瓦斯等管線相當複雜，必須由業管單位相關人員去操作才安全。
理論上資訊系統可以納入相關的管線管理系統，但是因為管線的管理系統相當龐雜，未來會以什麼形式去提供或介接，首先還是必須經過雙方同意，另外還有一些技術問題尚待克服，基本上還是由業管單位去執行較為可行。
| 問：
根據我們的瞭解，目前仲琦在國內警務 / 消防 / 救護的系統建置上已經居於龍頭地位，並且在許多新技術的引進上成為業界的標竿，請問未來仲琦在這一方面業務的發展，將會朝哪些方向去走？對於國內產、官、學界又會帶來哪些影響？ |
答：仲琦在國內警務/消防/救護的系統建置上一直十分努力地耕耘，我們一直很努力的去思考怎麼去改良，還有如何提供更新的技術和功能讓客戶使用，就像我們為什麼引進
iPush® Server 平台，這是其他業者並沒有去考慮的問題，但我們會十分認真的思考。
像 iPush®
Server 最吃虧的地方，就在於它是在背後的基礎架構，一般長官看不出來，容易認為是可有可無的東西，但是它卻可以實際提高效能，十分重要，一旦放進系統架構中，對於我們所服務的單位而言，顯而易見的就是成本的增加，但是我們卻仍然願意在不超出太多成本的考量下，將
iPush® Server 納入，讓客戶能擁有更好的資訊系統，這是我們的經營策略，不會改變，但是政府的預算執行通常是頭痛醫頭腳痛醫腳的狀況，當太平無事時，預算的編列可能就會縮減。
我們期待未來政府仍然會固定撥出一筆持續維護的預算，能讓我們能夠繼續去改良進步，而不要只是不斷的投入新的專案，爭取政績的表現，而忽視了在資訊軟體方面的持續預算投入發展，這將會切斷我們生存與進步的空間。
不過以這幾年的預算編列走向來看，由於天災人禍不斷，所以政府的確漸漸正視這些問題，算是讓我們覺得比較慶幸的
── 喔，這當然不是幸災樂禍。
| 問：
以仲琦使用 iPush® Server 的經驗，iPush®
Server 是否有需要改善的地方？ |
答：以目前的情況而言，在文字資訊與一般檔案的傳輸上沒有問題，但是在動態視訊的傳輸上，是未來必須改進的方向。因為未來消防監控會有許多錄影監控設備，相關的視訊影像必須加以處理，而目前
iPush® Server 處理動態影像的能力弱了一些。另外，由於連接點並沒有衝破數百數千的數量，目前看來資訊傳輸的速度雖好，但不一定保證未來可以一樣好，因為現在並沒有實際測出極限的負荷
。
未來在 streaming 的控制是不可或缺的，目前的監視系統一般都是用
DVR 在控制，我覺得這樣會讓資訊被切割，視訊資訊獨立一塊，這樣的平台並不完整，未來應該將資訊全部結合起來，透過不同的
adaptor 進來，文字、影像、video 全部透過不同的 adaptor 進入系統當中，所有的資訊也得以整合應用。因為目前台灣治安不佳、錄影設備相當便宜，這些資訊必須集中監視管理，並和差勤系統結合去做某種程度的控制，提高救援的效率，所以增加動態影像處理的功能絕對是必要的。
|
