政委，各單位原則上都到了。消防署陳文龍陳署長，因為他現在在立法院，他說待會立法院如果狀況解除他就會趕過來，那是不是先請政委先講幾句話

好，ok。立法院當然都有狀況，今天其實因為有逐字紀錄，大家就是想到什麼，就是想要做的，或是各界幫忙的部分就盡量講出來，然後我們會有十個工作天的時間，在線上進行修改，所以也不用怕講錯話，我希望我們先聽一下目前這個系統整合計畫初步的構想，我們再來進行實質討論，好不好，謝謝。

政委，葉執秘，還有各單位代表大家好，我是消防署資訊室劉主任，本計畫由我們消防署跟NCDR(國家災害防救科技中心)共同來合作，等一下會由我先報告。我們有一些簡單的雛型，等一下也會展示，接著再由NCDR作報告。

(投影片)這是我們的大綱，分別是發展藍圖，計畫架構、經費配置與推動期程。

發展的藍圖，包含跨域多元數據匯流、資料測站開放共享、救災應變整合服務，以及防災知識推廣演練等四大構面。蒐集相關資料，配合政府資料開放的原則，把這些資料做為我們防災應變的服務來使用，我們也會把它整合分析。

對民眾比較重要的防災知識的推廣與演練，我們這個四大構面由我們防救災應變到民眾教育都涵括起來。接下來由四大構面發展出八大主軸，等一下再分別報告。

這是我們整個計畫的架構，最底層是數據匯流，我們會把災防應變、智慧物聯以及媒體影像等相關的資料彙整，我們會以開放共享的方式做一個資料策展的儀表板及數據匯流資料庫。當然相關的資料也會開放給相關的單位應用，我們這些資料都是共用的。

最重要核心就是在整個防災應變資料整合平台，透過這些資料我們會做模組化，等一下會做個展示，讓大家知道整個架構；當然一些社群媒體我們也不要去忽略他，我們會跟NCDR結合，他有一些網路攀爬的資料，我們也會拿來應用。

整個防救災決策圖台，這個也是由NCDR來協助我們，我們會運用他的資料來整合。整個完成後，再透過網路服務，從全球資訊網及災害情報站來服務，也會做APP。當然我們會運用一些比較新的工具，把原來的EMIC改成RWD，讓相關的人都可以運用不同的行動工具來使用，這是我們整個的計畫架構。

接下來作細部的報告，跨域多元數據匯流，包括建置數據匯流資料庫，以奠定防災應變基石，因為系統要跑一定要有相關的資料，所以

接下來我們會建構領域資料標準框架，讓大家能夠互相的溝通，有一些資料標準不一致的話，其實是滿麻煩的。接下來跨機關資料的交換，像水利水保、氣象衛星等等監測資料，其實都是很寶貴。各單位各有建置，大家互相來運用，他們有的也需要我們防災應變中的即時資料，大家都會來做交換，強化資料蒐集與豐富性。

除了各防救災單位，我們也會運用新聞或社群豐富的資料，畢竟社群的朋友有時候有些資料是我們所需要也是我們遺漏的。

資料策展開放共享，我們有研發出一個資料策展的儀表板，他可以顯示一些資料的分析策展及服務狀態，我們等一下會做實機樣版展示。

災防應變整合服務是我們防災應變的核心，我們為了達到一站式，希望所有的民眾從災害情報站進入－－其他人員可以用分眾的方式從系統登入，初步歸類為系統管理者、指揮官、防救災業務人員或應變中心的進駐人員。

我們希望透過不同的使用者有不同的功能，讓他比較方便使用，有別於現在的EMIC，現在EMIC一打開，所有功能都打開，希望利用分眾的方式，類似像是我們現在的手機，需要什麼APP就去下載，這樣子對他們使用者會比較方便。

我們從事EMIC這麼多年，就使用者而言，他們實際上我只會使用到EMIC的兩、三個功能。因為在應變中心開設時是分組運作的，他不需要那麼大的功能，我們希望能夠透過這次把整個EMIC系統作改變。

這是我們防災應變整合服務的雛型，如我剛剛的報告，如果我進來是防救災人員，這些災情管理、災害影像、、、這麼多功能，他可能只需要用到幾項，那我們希望設計系統有一個讓使用者去篩選他要的功能，他看到的就是他要操作的東西。另外，我們這次特別讓地圖跟文字兩個模組可以互通，以前他們在填報資料都是透過文字，我們現在如有災情，他再地圖上點下去，就可以跳出一個框框輸入相關料。

同樣的，他如果在辦公室或是應變中心的人，他可以透過純文字方式輸入，當然他在這裡輸入地圖這邊就會產生相關資料，我們希望讓大家知道災情最嚴重在哪裡，我們透過動態視覺災情通報，相關連結的就是119、1999、媒體，甚至110，如果有災情發生，小黑點驚嘆號會從上面掉下來。就發覺台南市區很多災情，或是很多人回報災情，我們就知道這裡有比較重大災害，可能是重災區。透過動態展示方式瞭解，不像以前都是彙整數字，數字出來一連串才在地圖上面，希望有動態展示。

知道哪裡有災情，救災人還沒到之前，如果能連結相關影像，可以看到即時狀況，對我們來講是有很大幫助，也可以讓指揮官做很好的判斷。像以前我們會知道哪個公路道路中斷、塞車，但你去看它，整個車流是順暢，這個可能就是誤報或謊報；又或是有翻車，或已塞車了，但是看影像車流順暢，就知道那個狀況已經解除，我們有結合NCDR相關資料，也會介接相關影像，比如災害點附近影像可以做搜尋，方便我們做決策。

這是防災知識的推廣，防災工作除救災人員外，最重要的還是民眾，我們用他們比較能夠接受的方式，影片、手冊或是數位學習，放在臉書或是Youtube上面，讓他平常接觸就能看得到，能夠辦教育訓練。

另外，我們希望能夠推展全民網站演練平台，他進去平台能夠做地震的演練，家裡地震怎麼做逃生演練，都可以進到這個平台，選擇要的項目來做演練，這個是分年計畫的細部，我就不在這裡做報告。

這是我們整個預算的配置，當然從四大構面出來的，衍生出來的每一年的分項，其中NCDR會協助我們做災害影像及圖資的整合，總共的預算現在預估是3億5,250萬元整，NCDR有分配到7,600萬，後續就看立法院的審議來做調整。

雖然整個前瞻計畫我們研提了，立法院也尚未核定經費，但是PMO團隊很幫忙，整個民生基礎建設的計畫都已經過了，我們在等立法院核定預算，在核定之前我們還是持續在進行。我們會成立專案辦公室來進行需求訪談，研擬計畫書，希望在10月中能夠招標出去，畢竟時間有一點趕，今年如果可以做的話，重點會放在明年，明年比較有成效，因這段時間有一點趕，還要驗收。

這個是我們災害情報站，因為能讓民眾看到即時民生資訊，所以我們特別在6/27改版，一方面有增加社群分享功能，像臉書，還有即時訊息的輪播；若有一些颱風、即時訊息，我們會在這裡輪播。

嵌入NCDR圖台在中間的部分，另外就是有設計重要消息的發佈，災情看板、消防署粉絲團專區，希望民眾一進來，在颱風的時候可以看到資訊都在這裡呈現。目前在進行壓測，預計21號會有報告出來。

一個政策是需要溝通的，所以我們希望到北、中、南、東，各縣市政府推廣，讓他們知道我們在瞻在做什麼、內容是怎麼樣，對他們有什麼幫助；另一方面也可以聽聽他們對我們前瞻有什麼建議。畢竟我們EMIC的系統是給大家用，他們以前都是看到系統以後才知道，所以我們希望他們知道我們目前的構想，未來會產生什麼幫助，或是他們有什麼需求，我們希望在這個訪談的過程中，或是報告的過程中，跟他們做相互的溝通。

我們接下來做一下資料儀表板的展示。

接下來做概念性的展示，請政委給我們指導。第一個是資料策展儀表板展示；第二個是EMIC圖像化與行動化的概念設計，請政委給我們指導。第一個主要展示跨域蒐集各類災防應變資料後，進行資料監控管理與策展，資料策展儀表板希望可以呈現三個元素。第一個元素是對目前EMIC系統做監控，包含EMIC現在的訊息平台、單一簽入、圖台等。若我們發現綠色表示正常，發現紅色表示有故障，這個時候可以檢視與復原系統，改善系統營運狀況。第二個元素是對資料的即時監控。過去，我們蒐集很多資料，這些資料有沒有正常送達或斷線，都不知道。當災害發生時，若透過CDX介接，可能造成資料延遲，我們希望將來可以直接介接資料來源機關。

資料即時監控畫面左邊主要顯示資料來源機關，如交通部(包含氣象局、公路總局等)、經濟部(水利署、水保局等)。藍色的部分是顯示今天送達的資料，如交通部氣象局送給我們什麼資料？從畫面中我們可以看到衛星雲圖資料有很多種(包含藍底雲圖、可見光雲圖、紅外線雲圖、高解析雲圖等)，目前送達的是藍底雲圖影像資料。

另外資料來源機關還有經濟部(包含水利署、地調所等)，我們發現水利署今天送達資料為水庫水位資料，很正常流到水利分類資料庫中。畫面紅色部分表示資料傳輸斷線，例如農委會水土保持局的土石流警戒資料，現在是斷線的，我們就可以快速檢查哪個環節出問題。目前初步將災防應變資料分為水利、交通、地震、氣象、社群媒體等類別。畫面右邊主要顯示各類別的資料摘要說明，例如水利類，我們發現前三大資料集為累積雨量觀測資料、豪大雨特報、預測雨量等。即希望透過視覺化方式，進行資料的掌握、監控與管理。

第二個雛形主要展示EMIC圖像化跟行動化的應用。不管是民眾、救災人員、指揮官或是志工（合作），都是統一由災害情報站進來。如果是市民，就會看到情報站首頁；如果是救災相關人員，可以透過登入具有不同權限，而不是像現在整個功能都攤開要點選，這樣可以達到分眾分工的效果。假設我們是救災人員做報告災情的工作，以前是用登打，現在希望可以結合圖層，直接點選位置後會自動帶出目前時間、地點、經緯度點位等，並直接選取災情類別，更方便以動態、即時更新報告災害。未來，希望可以做成RWD模式，帶著平板或手機就可以直接點選，方便做災情報告工作。當然，如果習慣用文字模式的話，也可以用文字模式輸入，跟現在的是一樣的。

  還有，即時影像對於災情是重要的工具，我們來看CCTV管理部分。在影像管理的部分，我們可以把圖跟災情同時一起呈現。所以，當有災情發生，我們可以自動搜尋附近有哪些CCTV，並可以點進去看到災情案件的附近情況；以前是分開的，現在把它整合在一起。我們將來希望可以結合NCDR目前有六千支影像、高速公路開放的，或是因為救災議題，縣市政府可以提供的。可以用來災情報告、可以協助指揮官跟救難人員來追蹤災情的處理情形，這是我們要展現的功能。

接下來，我們來看指揮官的功能。以前的災情報告都是統計，每三個小時做一個報告的表格跟長官會報；現在，我們希望災情可以透過動態的方式呈現。畫面展示的是我們介接災情查報、119、1999或企業查報等災情案件，透過像雨滴般一直掉下來的方式呈現，而畫面上的這些圖示是以消防署14類的災情做分類。此時，我們就可以馬上知道說哪個類別的災情可能在台北、台中、台南是比較嚴重的，而不是看文字。如果我們想看到底是什麼災情，可以點擊某一個災情案件來看。例如可以知道這個災情在嘉義市、精確的座標位置、處理情況、案件類型等等，再進行指示派遣。我們也可以用查詢方式找到想關注的災情，跟以前是有很大的差異。

我們不只做網頁版，也做了行動版的展示，不管是在辦公室還是在外面，都隨時可以看到畫面。我們現在用iOS系統的手機進行模擬展示畫面，指揮官看到台灣地圖上，災情案件像雨滴一樣一直掉，即時定位在地圖上，上方有即時廣播訊息，下方會有14類災情案件的即時統計，可以快速掌握目前台灣的災情狀態。如果想對每個災情細部查看，點擊一下可顯示災情的簡單報告，更可查閱災情案件的詳細情形以及處理情形。若還沒處理，指揮官可以直接進行指派工作。如果想查看災情附近的情形，可以點選CCTV圖示，這有助於指揮官做判斷，要派多少人去，這是我們想要做的。另外，常有民眾會現場直播。未來，可以透過新聞記者或是民眾報案提供直播，有助於我們做判斷，協助救災工作。

這是初步資料策展儀表板在網頁版與行動版的展示，謝謝。

我們消防署報告完，接下來請NCDR，謝謝。

政委，各位先進大家好，現在由NCDR報告我們目前的進度。現在NCDR這邊主要針對大眾版部分做開發。謝謝消防署的協助，已經把大眾版嵌入到災害情報站。

目前的架構如這張圖，在中華電信，謝謝政委的協助，在HGR已經將它牽進去，目前包含AP伺服器、SQL伺服器還有兩個File伺服器部分，介接的資料會透過我們這邊做連接以後，拋到HGR在提供服務出去。

目前整個架構盡量減少讀取資料庫的方式，改為讀取檔案，服務的人數可以大幅的上升。今年在上半年主要重點在水、電、民生、颱風路徑、土石流、示警燈號等等，已經透過網頁方式OpenAPI方式，提供相關服務。在裡面總共包含六項資料目前是放在消防署EMIC裡面。

所有的架構不前是在中華電信的HGR機房做測試，也感謝政委辦公室協助，在這邊測試的結果，包含像說水庫洩洪、道路封閉、綜合資訊這三個圖層資訊，目前能容納同時上限一萬人，平均回應時間都在毫秒等級，可以提供相關服務。其中幾項目份他的JSON檔比較大，可能會造成HGR網路頻寬不足，這塊也謝謝政委辦公室提供後續的方案，我們會將比較大的JSON檔放到外部的資源，提供相關的服務。

另外在整個大眾版的部分，目前除了說現在有的名聲資訊以外，未來會持續擴充相關情資服務項目，氣象或地震資訊等。這塊在後期會持續納入大眾版裡，在災害情資網對外公開的資訊，相關頁籤就會放在大眾版裡面，提供相關應用。

針對HGR部分，目前是到10月到期，要再評估服務的地點。目前有兩個方案，看是不是在持續租用HGR，可能要等HGR的費用出來再去評估。第二方案也有在跟內政部討論，是要轉移到內政部的機房。內政部機房整個設備的可擴充性及對外服務頻寬，還不甚瞭解，還要跟內政部討論。再針對這兩個方案選擇一個比較適合的方式做後續的架設。

第三部分，明天開始建立應用決策的共用圖台，我們會考量幫這圖台使用災情的資料，透過視覺化儀表板的方式，來產生圖台的運用。包含盡量激所有資料歸納整理，在不同比例尺可以看到不同統計人員資訊做運用，這樣的一個圖台。未來圖台希望可以透過大種版一樣OpenAPI的方式，可以讓使用者馬上嵌入到介面做使用，以這樣的方式做開發。

好，謝謝。

我有好多想法（笑），我們一個一個，也不是什麼，就是討論而已。

第一個就是說，因為最近我們在處理資安的事情，上次那個Petya有幾個企業被他打，整個ERP系統跟資料都被鎖住，三天整個不動。這個東西會不會在我們的系統裡面發生？所以我們上個月已經麻煩趨勢、合勤跟一些IoT公司來幫我們開一個標準的Guideline跟Requirement跟查核的模式，到時候我們再發給大家。

我們會在民生公共物聯網的架構底下要求一致的標準，到時候再麻煩大家配合。

因為這個現在越來越嚴重，特別是IPTV這件事情。災防中心介接很多IPTV，這個壓力會很大，因為IPTV 90%都是中國大陸做的，裡面的韌體等等，其實壓力很大，我說真的，這是第一個部分，這要小心。

因為過去有一個國內的A級單位，被駭進去是因為繞過中央氣象局，這個經過第三方的狀況所造成的問題其實也很大。如果我們在這邊開一個洞，其實其他單位跟他介接的也會開一個洞。我們希望在一個月內協助大家，訂這三個事件。

剛才我們講到很多重要的查核點，其實我們都不曉得什麼時候可以完成，麻煩計畫這邊給我們一個清楚重點的查核點時程，你可以從第一列開始寫，不一定要寫幾月幾號。可以從計畫開始後加六個月、十二個月，所以重點的查核點麻煩大家一下。

再過來就是我們的資料裡面過去相關事件資料的連結，這個對決策系統的協助分析服務是很重要。過去經驗才是災害分析的基礎，我不曉得多少可以連結出現，因為過去我們建立大量資料，是不是在事件出現的時候可以Call out for Help。這樣大家在分析討論的時候可以不用腦袋再去想，很多資料自動跳出，這個應該對未來是有效的。

跟縣市政府介接的部分，我知道NCDR有另一個案子在做，但是我覺得有這麼大的資料庫，我們可以更進一步的做一件事就是：縣市政府其實決策力是很低的，大家知道，因為大家靠中央－－每個縣市還是有區域跟心態的差異性，從歷史資料就知道。

有些人喜歡颳颱風，有些人喜歡土石流，有些人喜歡淹水，每個人喜歡的項目不一樣。所以我們怎麼樣做一個介接的服務，基本上是決策服務，不是幫他作決策，我們必須提供一個決策的服務，不是幫他作決策。既然我們提供這麼大的資料庫，沒辦法作決策服務的話，對縣市政府是沒有意義的，他只看到很多資料，沒有這個專業來做服務。

再來就是這個災情事件，災情事件發布的時候是透過這個系統派遣派工，還是有另外的系統來做。

我先來回答。

對，這個。

如果案件是從119進來，我們消防局的119會先派遣人車出動，他們會轉到這個EMIC系統，每個案件都有一個任務指派。

我的意思是說，現在很多系統的做法是：災情派遣派工是在同一個平台做，每個人都是透過同一個登打的方式來做，我派給你就知道什麼時候上的，什麼時候完工。這些追蹤在剛剛報告是看不到的，就是事件的追蹤，就是誰在什麼時候接到這個指示，他已經上去說我收到了，什麼時候結案，這個事件的追蹤也是很重要，可以從歷史資料分析這個事情平均要處理多久。

接到這個任務多久可以完成，不管小的或大的都可以分析出來，其實對事件評估處理非常有效。事情不會永遠是新的，大部分是舊的比較多，建議事件追蹤可不可以放在裡面。

民眾教育的部分，我不知道民眾教育怎麼做，但是我建議像這種東西，對於太資深的、年紀比較長的是沒有用的。我媽講的，人過了50就不會改了，所以不需要對那一部份推太多的力量，其實K-12是比較有效的，社群是比較有效，這些是要一群人才有效。

K-12跟社群才是重點，應該請他們協助建立教案教材，他們才吞得下去。如果我們用這麼高深的來做的話，小孩子每次都說你們講的東西不是我們的語言，這東西就打垮了這個東西的有效度。我建議請他們協助建立教案教材，不是我們給你個讓他們去用，這樣不是很好。

這裡面我們有沒有避難地點的資訊在這平台裡面，有嗎？所以開啟之後，我們可以知道多少人進到那個點嗎？我在日本有看到這個東西，他們可以很快的通報下去，假如海嘯，多少人在多少時間完成避難的集中，然後避難的點裡面都有head count，也是另一種事件追蹤的機制，只是是高度自動化，這次是在裡面看到。

我建議這個東西應該要有定期大小改版頻率，我們六個月大改版小改版沒有關係，總是要有定期改版，這樣我們才會記得每一陣子我們就要多一些調整資訊，不然可能一輩子到下一個事件之前都不會改版。

其他的很多部分，因為我們都有其他工作小組討論，我們就不要在這裡贅述，這個就是說，那個分析。有看到很多資料，但是沒看到很多分析。很多東西需要專業分析，資料沒以分析是沒有效的，因為對決策或是事件處理跟預防其實是沒有效的。分析這個能力與功能是不是應該放進來。你有這麼大的資料，要做什麼樣的分析，這個是不是可以放進來。

大概這幾點，謝謝。

好，一共九點，不曉得大家還有什麼想法，就可以一個一個來。剛才派工那個已經一定程度上說明了，其他就請這邊。

我想請問...

請說，我們從第十個開始。

我這邊是比較從計畫面，第一個是經費部分，因為剛才列的總經費是3億5,250萬，可是我們這個計畫核的是4億。

因為119(指揮派遣)的部分被刪掉了。

對。

另外一個計畫的東西，EMIC以前是災防雲，現在國發會有一個電子化政府，106到109年也有提出救災雲賡續計畫，那個計畫跟這個計畫彼此關聯是怎麼樣。剛才我們有一個計畫架構圖，是不是可以透過那個計畫架構圖稍微解釋一下？

另一點剛剛葉副也有講，目前這個相較之前已經改善很多、也提供很多比較即時的資料，可是這個資料因為在相關的工作會議裡面，消防署這邊出席的人員不是很多，現在資料要介接到國網，國網那邊有比較大的分析跟運算資源，再提醒一下消防署，將來跟國網介接的部分要確實、特別留意，而且一定要做好，以上。

好，還有其他問題嗎？我們可以統問統答。

主席，各位與會的長官災防辦這邊有一些建議，這是EMIC系統的整合，主要的功能介接內容比較是朝風災或是地震、水災這樣的天然災害規劃。但是其實災害防救法其實還規範了海難、空難、動植物疫災還有一些生物病原災害，因為是要打造一站式的災害資訊整合平台，是不是外來這些災害的相關資料也是要納入介接考量？資料呈現向農委會的防檢局就沒有納入這個資料庫，整個資料庫內容呈現還是要去重新檢視一下。

另外一個就是交通類型的災害，主要是針對公路呈現，其實在風災的時候如果說碰到連續假期，海運跟空運這塊也是要納入考量，所以可能未來系統在呈現方面，海陸跟空路也是要整合納入。

第三個意見就是這個災害情資網呈現的方式主要是針對災害的應變，呼應剛剛副執秘講的，災情事件他在完成之後可能也要有一個呈現的頁面出來。因為像0613的豪雨就有遇到類似的問題，鹿港的淹水其實已經處理完畢，那災情的揭露可能就是要處理完，就要在網站上可以讓民眾或媒體知道，這個災情已經處理完，非常公開透明，比較不會造成說媒體一而再再而三的重複報導，一直在媒體上面呈現。

以上三點，謝謝。

好，都是非常好的。

我想到可以補充14B（笑），不要再加了，我看得眼睛都花了，還滿多Action Items。14B就是，因為剛剛講到媒體跟社群，我們不是要建立API嗎，是不是直接Push給這些媒體？因為現在媒體都直接接訊息進來，直接轉到他們系統上，如果直接接上去就不會有這個問題，我們API直接Push出去給媒體，反而很有效，可以減少他們工作量，他們也會很樂意，資訊正確度也可以提高，謝謝。

OK，14項，還有第15項嗎，歡迎盡量提出（笑）

沒有，那我們就一個一個來處理。看看是要什麼順序都可以。

我知道推送部分，NCDR之前有一些經驗。資安這邊其實我剛剛聽到的是說，我們首先整個公共民生物聯網會有一致的資安標準。

是。

這個其實遵循它就好，沒有特別需要做什麼。

是。

另一個就是說我們要確保IPTV來的訊號，我們要假設他是不可信的，甚至是惡意的。所以如果是IPTV接近來的資料有任何不是完全，CSV這種不太容易攻擊的資料，他只要有任何可能進入我們執行的Pipeline。例如：他直接給MP4或是串流，你要假設他裡面全部都是木馬，是想要緩衝區溢位，不是什麼善意的東西。

在這樣的情況下，我們在建置的時候，接的關卡就要進行清洗，或是一開始就明確定義格式，讓他沒辦法藉此攻擊。這是第一項我聽到的事情，這個實作上如果有困難或是覺得這個問題本身需要重新提出或是需要調整的話，可能就要提出來；不然的話，這個就會變Action Item。

報告政委，IPTV這一塊的確有滿大的問題，我們介接各單位現在格式都不是很統一。我們現在接的內容有MotionJPEG也有H.264，或是中華電信又是RTSP，不是正常的格式去轉，所以很多種。我們再接的時候有很大的困擾，要因應每個單位。公路總局就比較單純，他有中間程式可以轉，出來就是一張JPEG檔，這塊建議後續要討論一個通用格式。過去發展過程大家格式不一樣，現在面臨到這個問題，之後可能要針對這塊去討論。

你們有沒有偏好的格式？

其實我們比較偏好的是MotionJPEG，他的支援度也是最高，像H.264或是RTSP在發展過程當中，像去年開始要導倒一些Plugin的部分，所以我們又要再透過再轉一手，轉乘MotionJPEG的方式做呈現，所以建議是說是可以統一。現在最簡單靜態就是JPEG，動態就是MotionJPEG。

事實上MotionJPEG技術夠簡單也已經非常久了，要進行資安攻擊的機率比較低。

新的codec要看用什麼方式來轉換處理。如果這邊已經有偏好，我們接下來工作的時候就把介接的Hub當作工作項目的一部份。如果內政部或國網可以運行，反正哪裡有CPU哪裡運行，我覺得這是很好的具體建議，這樣也減少IPTV如果什麼Codec都收，如果他突然丟有問題的東西出來，我們也很難做滲透測試，因為他的組合太多了，我們至少把格式的部分做控制。

我還是再請教一下，即使我們用MotionJPEG，那我們資料進來有沒有做什麼清洗？

目前是沒有，我們現在接的話，例如公路總局我們是接固定IP，回來這邊的話，有幾種做法。透過我們中心去做，或是導到他們那邊去讀，不會直接讀到我們中心，所以有這兩種方式在做，沒有做資料清洗的動作。

我沒有記錯的話，MotionJPEG就是一連串JPEG，我覺得JPEG那個Codec應該還好。它主要的問題是頻寬要求非常重，因為他沒有做現代的這些壓縮，但是如果我們每次看的時候就只是稍微監看一段時間，感覺上應該是還好，但是比較沒有資安顧慮。

像我們現在監看的話1秒1張應該可以，大部分是一秒30張那個應該不用這麼頻繁也可以。

像剛剛蘋果發表會的那種Demo，應該不會實際在這個系統上出現，我們要的只是看雨多大，橋有沒有斷掉，他等於是很多張照片，一秒一張照片，我真的覺得還好。當然還是要一些注意，但是他的攻擊層面滿小的。如果沒有別的我們1就這樣子。

接下來2就是查核點。先從特別預算拿下來，再從招標開始算，這個具體是幾月？

其實最正確是預算下來，就開始訂招標RFP文件，招標評選的點大概10月多，有廠商得標就開始計算後面流程，當然在RFP中會訂得標後多久要交什麼東西。那剛剛副執秘要的我們就會在標案中去呈現，在RFP中就把期程稍微定出來。

瞭解，剛剛說明年汛期上線第一版的時候，意思是幾月？

汛期是五月一號。

五月一號，所以基本上大概有半年左右的全部作業時間，但是還包含測試，所以實際開發其實並不長。只有三、四個月，以第一期來講。

系統會陸續完成，但是我們沒有辦法在五月一號全部上線，會有部分系統一直上線，我們要讓長官或是民眾知道我們這個是有績效的，不是說規劃一整年到年底才有整個東西，我們重點是放在防汛期前有什麼東西，跟去年有什麼不一樣，那今年可以為民眾服務什麼。

瞭解，不過最近不是有一個文化說，在汛期中不會上版。

對，我們講是可能會成立應變中心，如果動系統比較危險，盡量不去動。

所以說就是五月一號，最多五月底，看到的就是一整年的版本。概念是這樣子，這個查核點相對是容易寫的。

對，但是現在看起來是沒有後續，就是看的不是很清楚。

就是說明年五月來不及上的話，其他哪一些是逐步的測試驗收，我們等汛期過去後明年年底驗收的項目有哪些，這些項目要Groupping一下。就是說如果哪些已經知道不可能明年五月完成的，至少那些是切出來，大家比較不會有不合理的期待，大概是這個意思。

嗯。

如果這樣ok，查核的時程就分成確定五月一號可以上的，還有不能上的，還有在之間的。後來的後續規劃這邊已經想到，但事實上會超過第一期特別預算執行的時程的話，那個就是Nice to have或是For the future。

嗯。

那接下來3：關於歷史相關的資料。圖裡面有所謂的資料產品，已經策展過的某個個特定災駭的報告。就是發現這次發生災害他看起來就想之前的某兩個，然後它就自動提供一些分析報告。請說。

現在災害情資網有時間回溯功能，他不像是個分析報告，只是讓你可以回到那個時間點去看當時發生什麼事情，像當時颱風路徑，當時的災點，在過去我們建置過程當中都有留存歷史紀錄。所以你可以回溯到當時的時間點，看發生什麼事情，這樣的一個功能。分析報告的話像中心每次災害事件都會產出一個報告，會有事件不去做處理跟運用這樣子。

所以他的運用基本上是我開另一個電腦放在這邊，那個螢幕上面顯示上次某個颱風來的實際情況，或是把事件簿開在那邊。但是如何縱整，目前是我要自己想到去看某一次的時間回溯，另一個是說掉出來的時候他跟目前的關係是人腦在判斷，是工人智慧，不是人工智慧（笑）。

剛剛這個葉副主要問的就是這兩個，我看一些雨量資料，系統就自動建議一些資料跟過去的某幾要比較相像。

第二個是說，事件簿調出來的時候是不是可以加一些自動的分析說，當時發生的事情做的判斷，跟現在的哪些比較相近。其實都是一些推薦系統，不是說這個調出來就是一定要照著做，這樣就完了。

而是只是說把最相關的，不管是事件或是判斷，把它調出來，這不曉得有沒有做過類似的。

其實我們在颱風的話，氣象局說這個颱風跟哪個颱風類似，我們可以在這系統裡面調閱當時的資料去看；這部分還是工人智慧，沒辦法說人工馬上去做，可以作為下一步研發的方向。

我建議就是說，工人智慧沒關係，希望說可以做簡單的人工智慧，就是非常笨的關係度。所以他可能會把前三大或前十大的關係調出來，這樣就好了。

這樣做分析判斷的人就可以知道哪時個跟他是最接近的，這樣他就很容易從過去趕快做歷史研讀，很快可以協助決策，不然再撈資料不知道要撈到什麼時候，或是每個人都在想像那件事情怎麼處理的。其實，它經發生了嘛！

其實不管是人工智慧還是工人智慧，使用者看到的界面是一樣的。我們在做使用者體驗研究的時候有Wizard of Oz 綠野仙蹤法，就是看起來像人工智慧，事實上是人在幫忙選。

至少在進行開發或測試的時候有人在假裝是人工智慧幫你選，這件事情會不會有幫助，如果沒有什麼幫助，這件事就保持在人工作就好。如果發現每次都有幫助的話我們就稍微投資一點時間或一些演算法下去，去把這部分自動化。只是探索，沒有要馬上變成 Machine learning，這樣可以嗎？就稍微往這方向想。

第4個是說，縣市政府根據區域差異都會有決策流程，包含地方的一些系統，泛指工人跟人工智慧的部分。

想問的是：API都已經接出來了，是否有可能Survey一下縣市政府的決策流程，我們可以提供什麼決策服務？接到當地的決策系統，或是他們沒有開發系統的能量，我們這邊可以幫忙一些東西。

報告政委，這個我們在專案的地方已經有在做相關工作，過去情資網也是。可以變成一個地方自己想使用的情資網，可以做簡單的設定就可以把相關情資放在裡面讓他們使用。我們今年有跟新北市合作，他提供資料給我們，我們也可以幫他做一些簡單的客製化，像API的部分回饋他們。其實每個縣市他們的程度不一樣，台北市他們資源比較多可以自給自足，中南部的話就滿喜歡這種方式，資料介接進來再把資訊回饋給他們做後續應用。所以這塊是有持續在進行。

這部分我們請國發會已經通過了OAS3，國際標準組織Linux Foundtion下周會正式頒布這份文件，我們也會參與後續的幾個開發。以後地方政府特別要求你們寫某個端點出來的時候，建議用這個方式把它寫清楚，開了什麼明管出來。

這樣其他地方政府就可以說我要跟他一樣的，但是加這個地方或減這個地方，這樣子未來大家才能夠有一致的討論空間，不然每個縣市政府都有一大本說明書，這樣其實比較難討論。所以這個之後也參考國發會與工程會頒布的那個「共通性應用程式介面」的規格進行客製化，我覺得比較好。

那地方政府我上次去聯席會議，他們講的另一個非常有幫助的部分，之前常常需要登打好幾次，因為不同部會跟系統需要不同格式，如果這邊有辦法做一些基本的格式轉換，或是格式沒辦法轉換的話，可以一次填這兩個連集到你們系統，你們再去作分流。

其實每次災害發生的時候，他們只要稍微減少一點重複登打力氣，他們就多很多力氣做實際防救災工作。這部分我們也把他列進去，如果需要跨部會協商，甚至包含欄位這些的，就隨時跟我說。這個原則來做第4點。

當登打有派工的時候，這個事項的追蹤是否有在這個系統做呈現？

這個我們已經有做了，我們我們等一下做一個系統的DEMO。

不用等一下，現在就可以做DEMO(笑)。

這個我們在原來EMIC就有這個功能，不管你是透過119包含110都會轉接到EMIC，只要一成案就會有後續追蹤管制。我們之前DEMO的一直有雨滴下來那個是可以直接從地圖上點選，那這個是新的。我們DEMO一下現在EMIC的災情管制。

在管制維護這邊，我們可以看到通報來源的部分，大概就是企業或是災情、縣市自己上去登打的部分。我們看一下它的歷程，可以看得出來哪時候有受理的歷程，回覆說有沒有處理完，就是有被派到的局處處理的情形。

就是可以看到各個機關他們處理的情形，我們都是會呈現在這個上面來做管制。

我們在應變中心有災情管制組，他也會隨時監控這個項目，任務有沒有指派，對方有沒有收到，他們會做督促的行為。我們會監控到所有案件都結報以後，整個案件才處理完畢。

我看到跟我想像的，其實希望比這個更先進一點，我不曉得說現在這個人接案是有個APP接到通報，他組長按下去知道接到通報了，我到事件地點我按GPS Location，啪！上去我已經抵達了。處理完後最後驗收就可以上傳三張照片，然後再按一個，啪！就可以回來。

因為現在都是文字，在時序發生過程是沒辦法追蹤，連人什麼時候接到派令都沒辦法追蹤。

既然我們要改版，過程裡面是不是可以把文字加上半動態的時間點，這樣就很容易分析接到指示到抵達地點的時間，就可以算出來，或是處理多久，這樣才知道什麼叫合理、什麼叫不合理。例如：五分鐘會到的地方，你命令他三分鐘，這樣一輩子都不會到嘛！這就是不合理的要求。

我們應該可以把這個東西手機行動API的東西放在裡面，讓每個人都可以用手機登打的時候，這些事情理論上都可以做得到。前面都開放後面才追蹤這些事情，都會變得非常合理。我的建議是從文字跳脫到半動態的行為，謝謝。

我聽起來葉副的意思不只是這個東西RWD，讓他在手機上開得起來。而是Fundamentally是把這個東西也做成一個API，然後在手機上接那個API，在手機上進行繪製。即使一開始明年五月在手機上繪製還是跟這個差不多也沒有關係，但是以後某一個點上面，他可以用不同的方式做繪製，可能可以跟某知名叫車軟體一樣（笑） 。

至少他留下這個可能性。不是說明年五月就跟某知名叫車軟體一樣，至少我們前後端分離，是用結構化資料方式呈現在手持裝置上，可能明年五月還是只能畫成表格，這是無所謂的，但是要保留未來變成某知名叫車軟體的可能性（笑）。

所以這部分我想就是API First，這是一件事情。另為一件事情是目前登打是像追蹤，從你們中心人員以及被派遣人員，我們叫做User Journey，如果能夠趁這次規劃的機會畫出來，事實上可以請廠商畫出來。目前有API，User Journey長得跟現在一樣沒關係，我們未來要做優化的時後，才有優化的起點，比較不會辦現有的系統綁住。大概是這樣。

那接下來就是教案的部分，剛剛也規劃了一些經費，這樣剛剛具體的建議是說，實際上請K-12的朋友們，或是中學生甚至小學生，來參加這個規劃，也包含目前民間對防救災感興趣的朋友，是不是也把他們邀進來。

這部分的建議，在未來推動的時候會照這個方向來進行，謝謝政委跟副執秘。

接下來也是現有的，EMIC的功能，避難所的管理，是不是也是比照剛才知名叫車系統的規劃來做（笑）？

我們show一下EMIC現有系統，應該是還有再補強的空間，因為我們只知道有沒有開設，多少人的話就不知道了...

這部分跟政委、副執秘報告：縣市所應變中心所彙整收容資訊，會匯報情報站。民眾可以在情報站上依照縣市別，瞭解這個縣市已經開設的避難收容處所有多少，他們地址跟電話，這是我們避難場所資訊對外公布的部分。

其實在我們EMIC裡面，這邊可能來不及DEMO，我們有親友協尋系統。就是在剛剛劉主任提到的，親友協尋系統裡面，需要地方配合，他們有把避難收容的姓名資料能夠匯到我們EMIC系統裡面。

如果在台北的人不曉得在屏東的親友在哪個收容處所，只要在這邊輸入基本資料，如果說有成功的話，就會顯示目前在哪裡，這個系統目前開放外測，但是還要再做演練。報告完畢，謝謝。

這個系統是今年才開始可以用？

親友協尋系統。

這個是已經開發完，如果演練ok，還是需要地方政府配合。因為災時避難收容處所人員，必須要有時間，初期要先讓人員安定，才有時間輸入資料，在業務層面是需要來突破的。這部分涉及到衛福部那邊的業務，業務層面還需要再突破。

其實只要3G還有開設，其實這些朋友就會去社群媒體報平安。現在我們這個其實不是讓民眾自己填，是讓收容所的人填？

這部分的資料還是要來自避難收容處所管理人員的輸入，民眾可以上這個系統搜尋他要找的人，輸入基本資料，系統再到裡面去撈，把他撈出來以後，會告訴他說目前人在哪裡。

好，謝謝，很清楚。

有關收容處所這個議題，五年前就已經開始探討，我想NCDR也很清楚。

當初102年跟Google合作的時候，就有提出這項，但是一直以來都做不到。特別剛剛葉副有提到，有收容處所但是到底收了多少人，在系統裡一直沒有提供。

我知道之前相關會議，內政部也開過很多會議在協調。已經過了五年，內政部應該是已經有資料了，還是說到現在還是沒有資料？如果有資料，為什麼不接上來？

就是說目前事實上收容處所是不是已經有一個管理的，包含人數，事實上主要就是人數。也包含你剛剛說的要地方政府配合，這部分已經有人配合了嗎？

這部分因為系統要電腦化，最主要是說避難收容處所開設時，衛福部那邊有講，收容處開設時他們人力非常有限，有他們把資料輸入到我們系統裡面。當然之前也有跟內政部戶政司，跟他們協調希望避難收容處所的人員，除了流動人口之外需要用手工登入之外，戶籍內的人口，可以用戶役政系統的資料直接抓出來，可以省掉作業上的時間，這是我們一直在努力的方向。

這部分我們會在這次演練的部分，看能不能來做一些突破，就是要跟衛福部跟地方政府說，人力的部分...

意思是說，他們很難出一個專職的人來去問每一個進來的人身分證字號，然後把它輸入進去？

他們現在就是說，災時收容處所進來會先用手登記，是不是沒辦法在第一時間輸入系統。

因為他們一直在講說，民眾一進來最主要是要安撫，安撫民眾的時候其實，避難收容處所開設的時候所面臨的問題，其實沒有我們所想像的單純。他們從進來報到，到安置的一個過程裡面，很多事情要處置。

所以目前其實已經有人用手抄，好比說身分證字號，但那張紙目前沒有到任何地方。

他們就只有人數統計，通報到災情通報表，他會上傳到我們的EMIC系統裡面。EMIC系統就是由我們的...就是衛福部會就一個通報的部分，統計每一個收容處所有多少人。

先是目前收容處所大概是以縣市鄉鎮的收容人數有多少，這目前是在我們自己的公務系統可以看到，但是這部分資料是沒有去對外在情報...

但如果人數已經是統計性的，他已經不涉個資，他為什麼不能接過來？

人數他會用通報表傳送上來。

事實上是有嗎？EMIC裡面有人數資料？我們剛剛看沒有看到的原因，只是因為他前端沒有介面而已？

政委，我講實話，做系統的人，最主要是基層要整合，現在避難收容處所，是分兩個部會。疏散是一個部會，收容是衛福部，收容的時候，是不管公所是用手抄或是電腦輸入的。

當初本來是想說做類似使用身分證感應，就自動進系統，如果沒有身分證，用健保卡也可以，如果兩者都沒有，就直接線上登打也可以，對我們做系統來講是很簡單，但是對他們管理的人，收容所如何處理就是公所的事了，因為他們系統本來就是這樣子。

當初有想說把所有戶役政系統資料倒到資料庫裡面，等收容的民眾來了收容處所再做點選。但是那個戶役政系統過於龐大，我們是覺得，收容處所也沒幾個人，不需要把全國2,300萬同胞的資料都弄到裡面。

我老實講，是衛福部他們就是在應變中心成立的時候，每三個小時叫公所報一次資料，所以公所才會認為他每三個小時要回報一次。

其實我們也找過類似路跑的記名系統，只要災民進來掛個手環，就可以隨時進出，類似大賣場一樣，可以隨時掌握收留人數。但是後來這案子沒有成功，我們做系統的就回歸到原來的做法了。做以上的報告。

這樣我有聽懂。

我是覺得說，可以稍微再...現在手機的時代，剛剛講了很多可以當作部分的solution。因為你用紙本的話可能半天才會通報，而且數字誤差會很大。現在手機直接可以掃身分證，其實都沒有問題。可以把身上想得到，包括手機可以直接從Hotspot可以算出有多少人在裡面有開機。小孩子沒有手機沒有關係，大人幾乎都帶著。

我們不是要那麼精確，但是Lump sum一定要出來，或是有多少大人在這裡面一定要出得來。以現在資訊系統來講應該不是很大的挑戰。如果要求公所派出人，啟動事件追蹤，首先我們就知道公所會派誰，因為他馬上要用APP說我收到一個指示要到公所待命。

這個APP或API裡可以掃身分證被傳，也可以收機交換資訊就傳上去。我們可以很快知道誰進到這位置，不用在登打。手寫的東西應該慢慢讓他消失，除非是什麼都沒帶的，緊急避難的才用手寫。我覺得他是我們最後一道資訊防線。前段的防線在通訊系統完整的時候都可以做到。

舉個例子：請NCDR下載head count的影像一下就可以出來了，現在非常精確了正確率到98點多了，多少人通過這影像，會不會重複，就請他們撞上去，開啟的時候接過來直接算就可以了，或是中華電信hotspot都可以算出這個區域有多少人。

我的意思是：透過其他東西降低派駐人員現場的壓力，他壓力實在太大，還要安撫跟算現場的人。如果每個事件三秒鐘，他很快就接受，如果三分鐘，他很快就放棄了，因為太久了。原來一百人就三百分鐘他就掛掉了。現在手寫一個人大概要三分鐘，如果一百個人就五個小時，一定不做的，隨便寫一寫或是請大家自己寫。

用比較科技化的工具來協助這件事情，現場的人壓力也比較小一點，謝謝。

剛剛葉副講一個觀念，與其精度非常高，但花非常多時間，不如寧可就是多個precision都不怎麼樣，但加起來還是知道狀況。

不曉得說，在這個案子裡面有沒有可能加進一些規劃，另一個是說在這個案子外，有沒有地方政府在做類似的嘗試。

這部分剛剛劉主任有提到，我們會到北中南做計畫說明，在這個同時我們可以借用這個機會跟地方政府來進行這個交流，看實際上我們可以提供資訊的協助，他們這邊還需要我們配合的部分，來做一個綜整。

這部分有些縣市比較願意配合，我建議在資訊化協助的部分，找幾個縣市政府來合作一下；但有些人就是不愛陪你玩這個。

我們當初的規劃是有想找幾個縣市來辦，但就像我剛剛講的，業務單位認為這是衛福部的事情。如果你做完了，衛福部把整套都倒給你，業務單位的關鍵在這個。我們作系統的以現在的科技技術都沒有問題，關鍵在只要政府涉及兩個單位的都會有這個協調的問題。

意思是說唐政委找衛福部跟大家再來協商一下。

因為系統是衛福部的，要怎麼讓公所方便輸入，衛服部可能認為那是公所的事，所以我們這邊接收方的人就會卡在這裡。

要我找衛福部開會不是問題啊！重點是他來的時候你要有proposal給他，還是要有一個看起來願意合作的，至少一個地方縣市，願意跨部門合作。也包含他們那邊的承包方，跟其他的局處，對不對？

跟政委報告，我們原來有規劃先做一兩套系統，DEMO給縣市看，應該一定會有縣市會想配合，這樣就有示範的公所，等成功以後就可以全國普設了。

所以我們當初找了類似路跑活動的東西，設計將設備裝在一個行李箱。開設收容中心時就拖著行李箱，到現場架設感應設備，完成後災民隨時進進出出，就可以動態感應人數，我們當初是設計成這樣的。可是業務單位認為說那是衛福部的，但衛福部又可能認為那是公所要處理的。其實技術上是曾規劃過，就是行政面要協調。

我們就找衛福部來開會啊！這應該不是什麼問題。現在就是說你們之前已經有過一個初版Proposal，包含那個行李箱。

我們當初在前瞻裡面有寫進去...

這個不一定要綁入特別預算，我們拿公務預算也是有空間。

而且如果是試做的話，他成本並不是非常高，所以想說你們被拿掉那一段看是不是先寄給我。我先把它看懂，然後技術上我覺得沒有太大問題的話，可能就另案跟衛福部討論這個部分，作為一個實驗性質的處理方法。這樣也比較沒有明年五月一定要交卷的壓力，這個我想對大家也都是個壓力，所以我們把它切開來做，但我想這個還是值得去做。

因為如果已知卡在這邊的話，現在技術成本已經非常低了，我們也不能像以前等技術成本更低來作為藉口，現在沒有這個藉口可以用了，從民間看起來明明可以做的為什麼不做。以前我們還可以說太貴了，現在說太貴了外面是不接受的。

接下來就是定期改版這件事情，剛剛也有講說，汛期前上版，到冬天的時候做壓力測試。這是不是固定的時間點；如果是固定的，就明確的寫進RFP裡面，就是固定每年兩次或三次可以動系統的時間。

下一個第9個是在講分析的功能，剛才我們講的一堆資料的接取，如果有第三方或是NCDR這邊，或是學界，做了一些分析，見了一些模型，在這邊是不是有一個開口可以讓各地方政府或是民眾，接取這些分析。

這其實就像國發會的開放資料平台，他有一區放資料活化應用。意思就是說拿開放資料做活化應用的話，可以跟國發會申請說，我要把活化應用登在其中的某一區，讓其他人也可以來看這個資料的活化應用。可能是一個很簡單的可以掛分析的地方，不曉得這邊有沒有覺得困難或是需要討論更清楚的部分。

原則上應該是沒什麼困難，到時候我們會挑，哪些資料可以去做，在國發會的開放資料裡面提供出來。

基本上就是說如果已經是Open Data或OpenAPI 就直接掛載data.gov.tw上，如果有第三方拿這些去做應用的話，本來就有一個可以掛分析的地方。那我們未來在APP上或是網站上，怎麼樣在接近來，就看實際有活化應用出現的時候，我們來看這些分析服務可以放在介面的哪裡。

救災雲賡續計畫，是服務型智慧政府，還是智慧型服務政府，我從來沒有很記得。S2G裡面的計畫跟我們特別預算的關係，不曉得...

說明一下，這個賡續計畫其實是延續原來的防救災雲端計畫。因為計畫結束了，機房租賃的錢沒有著落，我們就訂一個賡續計畫。

除了機房的錢，還想做災害現場的即時影像，不管是用空拍機，還是如何把即時影像把現場傳回來。因為我們現在只要重大災害現場，會開消防署的通訊平台車去，畢竟現在4G網路這麼方便，可以傳送現場即時影像。

還有CBS的廣播，在原來的訊息服務平台並沒有CBS這一項。CBS已由NCDR已經開發完成，我們想修改我們系統，讓CBS可以透過我們訊息服務平台發送，這是跟前瞻不一樣的地方。

還有原來EMIC的SSO不是很穩定，我們有在計畫內編列一些費用，希望可以強化。跟前瞻不一樣的大概就是這些，其他還有一些宣導的東西。

意思是說他們是獨立的，沒有什麼路徑相依性。

名稱看起來一樣，但實際內容不一樣。

我的意思是說，沒有一定要這邊交前瞻那邊才能做，或是前瞻一定要做到什麼程度這邊才能做，是獨立的兩個計畫。機房的部分，不是用內政部的嗎？

當初在訂賡續的時候，內政部並沒有說要機房向上集中，後來開會決定預計107或108年我們EMIC的機房就會搬到內政部那裡去。

意思是說也沒有白買，舊機器搬過去，還是是說其實有白買？

內政部他們是說要看機器可不可以用，中華電信東七機房的機器可不可以挪用。他們有要整體規劃。

那就麻煩真的要整體規劃（笑）。不然就會出現賡續買的機器卻沒有用的情況。這部分沒有太大的問題。

剛剛講到運算平台，不管向上級中，放在東七或HGR。在公共民生物聯網總綱，只少要放一份應設在國網。這部分有任何困難或問題嗎？

沒有困難，相關會議就已指示，有一部分要放到國網。

我想這個就是資料跟API目錄做出來的話，用統一的方式介接。最大的問題是要測瞬間流量，這個我覺得也還好。國網硬碟幾乎是不用錢的（笑），即使用motion jpeg應該也是放得下－－這是為什麼當初到國網（的原因）。

接下來是，災防辦這邊提到的我們在分類裡面，對於防檢局的疫災，跟颱風地震無關的海難空難，這些態樣，是否在上面有呈現的方式？

政委報告，我們原來只希望前瞻只規劃颱風與地震，是內政部最熟，也是台灣最常發生的災害。

我本身也是國搜中心的搜救長，常常處理海難，海難發生，我們以前也成立過災害應變中心，也沒有用不到什麼系統，因為海難獲報後第一時間國搜中心都派船艇及飛機出去救援。交通部成立海難的應變中心，人員晚上可能都會縮編或撤掉，白天再回應變中心運作。若是空難的話第一時間就更緊急了，飛機上的人救完了，接下來就是以機上名單確認傷者或大體了。

老實講，我們不是很暸解他們的運作流程，我們希望先把颱風及地震的應變系統做好，到時候再看颱風或地震的應變系統，有哪些是其他災害可以用的，我們再來幫他們做規劃。所以我們沒有辦法幫那麼多機關規劃他們的應變系統。

像最近成立的豪雨災害應變中心，水利署使用EMIC時，就發覺EMIC有一些功能對他們來說並不好用的，所以計畫用模組化，以颱風或地震的應變系統為基礎，那些功能其他部會成立應變中心時可以用，就可以規劃使用。希望以後可以做到分眾還有分災，假設現在是颱風的就用颱風的應變系統。

希望以後各部會可以用他們自己的災害應變系統應變。我是覺得這樣是最實際的，以上報告。

簡單來講，希望未來有個自訂災害模組的功能。自訂災害模組應該是讓領域專家定義，而不是我們現在對疫災或其他來定義。能夠自訂災害模組的部分，是規劃在四年期對不對？是在前瞻裡面把它做完嗎？還是沒有？

我們目前沒有。

就是我們能夠承諾的是四年之內把颱風跟地震，弄到颱風歸颱風，地震歸地震，其他災害模組要四年以後再來討論，意思是這樣嗎？這樣可以接受嗎（笑）？

不好意思，是不是可以詢問一下？其實像海難，航港局他們也有一套系統，是不是協助他們介接？因為像剛剛劉主任講的海難，其實航港局他們的系統是可以看到海巡署他們的船，就是他們可以介接那個系統。

像疫災好了，防檢局他們有一個網頁專區，如果真的沒辦法做的很精細，是不是還是跟相關部會接洽一下？至少把這個系統可以介接在一起，那我們在使用的時候，就可以用單一網頁進去，還是可以查到我們要的災害的應變狀況，不用讓我們或民眾再去各別部會網站查詢，謝謝。

這邊講的就是說，前後端分離。後端我們理解到不會一下子出現到海難空難模組，但前端是否有可能讓別的後端，用這個東西來當作呈現的方式。

我們這邊需要做的其實就是把我們相關部分前端的程式碼或是API的接口，提供給航港局或防檢局，告訴他們說如果要串接的話要準備怎麼樣格式的資料。除此之外，我們也沒有辦法，因為我們真的沒有那麼懂。

（即使）沒有辦法提供後端應該怎麼寫，但是至少後端只要改成這個資料格式，那我們前端可以幫忙呈現。這邊希望的是這樣？到這個程度應該還好吧？

這個就會變主要維護還是航港、防檢在維護，但是新聞暨這上來的時候還是可以在這邊看到最新的災害情況，這樣子。但是我們這邊就不再後端去做開設或是派工，這樣可以嗎？這個程度。

這個程度，我們是兩年期？還是四年期？（笑）把它做出來。

這個我們回去討論一下。

好，回去討論一下，但這個我相信，至少四年期。

我們把它當作一個目標，這個我覺得還滿重要的。因為未來隨著系統功能越來越強，其他的公共民生物聯網裡面，凡是達到接近災害等級的時候，甚至包含嚴重的空氣

品質或水污染或地震速報，這些東西一定都會提出相同的需求，就是後端我們自己管，但是前端可以在這邊呈現。

所以我想這個是要綜合考量的，我覺得是很值得放到我們的範圍裡面。

接下來就是風災的時候，海運跟空運的服務中斷，這個目前我們是否有所介接，前端是否有顯示的方式。先不管公路或是CCTV，好比像說有一些航空公司停飛，或是班機延遲這些也都有結構化資訊，但是我們目前是否有顯示的方法？

現在看到應變中心交通部報告時都是用文字，目前什麼地方停航，好像沒有系統。在公路方面我們已修改F1表，現在只要輸入F1表，公路總局、國道、一般鄉鎮市區的道路都可以顯示出來。但是海、空好像沒有看到有系統可以讓我們介接。

這句話後面的意思就是說，如果他們有這邊就可以接？其實是他們有沒有符合我剛剛講的公開介接格式，之前我們這邊不會廣為宣傳，你要符合某個格式我們就可以接。但未來至少為有一個技術文件在那邊，這樣我們也須再分別請交通部那邊，能不能夠產出符合這個結構的東西？

基本上我們原則就跟之前討論一樣，如果是手寫或口頭描述，我們不負責猜他們意思；但是他們願意用結構化方式提供，我們這邊都可以顯示。

那接下來14，14這些也是我自己感興趣的，就是說我們現在在目前的這個災時已經接NCDR的資料。但是我在平時，目前沒有接。但目前沒有接的好處是說，我們可以顯示某個災害已經處理完畢，或是顯示一些對新聞媒體比較有用而不是很早以前發生的事情這樣。

在EMIC的首頁，這部分是不是有相關的規劃？據說當某件事情處理完畢之後是不是就在EMIC，災時轉平時的時候，那個平時能不能更清楚的講說什麼災害已經過去了，而不是看起來都是之前的災害這樣子。

我們有個首頁，有很大的Banner，有點像是手風琴那樣子的介面。

跟政委報告：我們應變中心成立，依颱風來講的話，會有新聞發佈室，都會有記者常駐在那裡。我們每次在做工作會報的時候，他們都會在那裡採訪，所以他們會知道哪些災情結束。

我要報告的是說之前鹿港淹水未退的新聞，在院長與地方首長座談會有提到，水利署他們有打電話到電視台去更正，但媒體就是沒有改。可能是媒體要填補那個時段，如果沒有新的新聞影片可以報，就沒有把它撤下來。

第三個是我們在應變中心會有新聞監看的同仁，如果看到新聞報導是我們沒有掌握的災情，我們就會納入災情管制。如果處理完的，我們就會回饋給媒體，我們會請公關人員跟媒體講，公關人員跟媒體他們有一個LINE的群組可以互動。

這邊的意思說我們不要追著媒體，我們可以自己當媒體啊。EMIC的首頁他也是一個媒體，對不對？

跟政委報告一下，目前針對這一部份，在今年的汛期，我們災害情報站因為有微調改版，在災害情報站的最新首頁會有訊息的輪播。

像剛剛劉主任提到，我們會針對災情監控，還有NCDR他們這邊也會有攀爬的一些資料，經過查證以後，我們會即時在災害情報站的即時訊息裡面做公佈；另外我們災時也會有臉書社群，同時會透過臉書來公佈。

媒體的部份我們會透過訊息服務平台，幾這個訊息，他到底是不是淹水，這個訊息傳給有線無線或是廣播電台。

這樣聽起來你們目前主動推送的方式就是LINE群組，可是就是說不在那個LINE群組的人，他知道你們跟媒體講了什麼？我的意思是說這個最新訊息跟LINE是同步的嗎？

我們這個等於是說，我們會同步把訊息放到LINE、情報站、臉書還有服務平台、現場的媒體，多方管道把訊息同步送出去。

我的建議是說，其實跟媒體直接開API對接，主動push出去，最簡單就是用Text模式，一直push出去。他們現在都是被記者打上去，可是打上去要時間，更正也要時間，他需要人工。我的意思是說資訊兩邊對接，我們push給他，這個事件已經解決。對他講他少掉很多工。

就是說我們用最古老的RSS好了，是不是在即時訊息公告的右邊，有RSS黃色的按鈕，按了就可以自動取得目前的即時訊息。當然不想用RSS或是用atom什麼都沒有意見拉，重點是讓他們容易去取得，去串接這樣子。

他也可以要求每十分鐘來更新，跟EMIC的網頁某一段直接更新回去，這樣他可以省掉很多人工。他只要點說他要哪個東西PO在跑馬燈上，或是哪些東西他要追蹤。而不是經過LINE這樣去分，這樣會跑很多程序。

我不反對用LINE，但是如果有一個公開的，在上面大家都可以看到的。我們就先講RSS好了，這樣的東西的話。大部分的媒體都有接RSS的能力，這個協定存在非常久了。是不是不怕人知道，只怕人不知道這些事情，盡量用RSS的方式。那這樣才不會說這個記者雖然在LINE群組裡，可是上搞的是另一個記者，靠人工中間還是會斷。

我們跟電視台建立自動介接的可能性的話，就跟中選會開票一樣，沒有接上的媒體他們會有自己的壓力，會覺得說我Lag了；但是在此之前我們還是需要一個公開而不是LINE群組的地方，哪怕是資料完全一樣我想都沒有關係。

就我個人的觀點，讓媒體越來越懶，他就越來越依靠你。這樣資訊的掌握度就越來越高，就不會很多假新聞出來。我們就是一定要養成媒體依賴我們的習慣，這才是解套的方式。就是減少媒體的負擔，資訊可以出去，一直餵他，他就會懶惰。

到時候他就會懶到連分析都不分析，就丟跑馬燈。你永遠最新的資訊就會在跑馬燈出來，這樣就沒事了。我的意思是說讓他越來越懶。

正在看逐字稿的媒體同仁（笑），剛才這句話的意思是：我們提供充分事實上的訊息，讓大家不用在做調查報告，就可以在做更多加值的新聞工作。我覺得這是一個非常好的想法。

我們要處理的14個應該都處理了，不曉得大家有沒有什麼最後想要討論或提出的？

好，那國網介接這邊確定沒有問題，那其他的感覺上都有實際回答了，所以我們這個案子我相信技術上面的想像其實我們之前已經充分都討論過了。

這邊主要我覺得兩個：一個要實質取得地方政府以及其他的部會，對這個新的串接模式的認同，我想這個還是很重要。

另外一個還是在明年五月上線之後，我們要做更多awareness的工作，就包含社群的教育，或是慢慢讓大家有一個發生事情的時候，這邊真的是整合式的可以看到所有跟我有關的資訊的一個概念，這部分不是技術上的工作，比較是文化的工作。

技術怎麼輔助，完全取決於我們在使用者分析與訪查的時候，有沒有足夠的把各個利益關係者，不管是登打的、做指揮的，或是實際在看的，這些朋友們的使用習慣納入進去。

剛才看了很多DEMO，當然我了解到比較像是早期的Prototype。像剛剛紅色表示斷掉，藍色表示會動，那灰色部分就不知道表示什麼（笑）。

這些東西當然有很多實質的一面開發，一面去問使用者的想像是什麼，然後我們可以去精進的部分。

我想一開始的DEMO不需要用到太怎麼樣，很多是在廠商跟我們對話的過程把更好的UI弄出來。

剛才葉副反覆提醒我們，人工的部分可以嘗試自動化掉，當然這裡自動化的意思是Heuristics，不是一下跳到GPU做的機器學習。但是在我們建置這些Heuristics的時候，確實也可以先用人去做模擬的方式。

若發現有一些自動推薦什麼真的有用的話，那確實也可以請廠商用實驗性的方法，去把它做更多的演算法上的自動化，但是這邊在講的是實際還是要扣合使用者的需求。

如果沒有問題的話，我們就很有效率地結束這個會議，謝謝大家。