我的想法是，我以前在矽谷做創業的時候，或者是我們現在在做金融創新實驗條例的時候，後面都有一個想法就是，即時你失敗或者是公司真的垮掉了，你只要垮的公開透明，他對那個產業就很有價值，等於他是幫整個ecosystem付了學費。
如果說他進來是在一個互相學習的角度，在矽谷有非常多公司他是拿了angel的錢，我自己的創意公司就是這樣，燒不到十分之一，就覺得這題目不好做，整個公司解散掉，然後九成的錢還投資人，但是因為我們中間的那個postmortem，就是我們哪裡做壞了，我們做的這些東西到最後都open source出來，給其他公司用，所以整個產業界是感謝我們那麼快失敗、那麼快證明這個business model不work，然後去做回饋。
可是這有幾個前提，一個是說有一個社群，這個社群是你現在開任何一個公司即使失敗四五次，這個社群都願意你回到這個社群來，但如果沒有這個solidarity的話，這種創新模式是無法想像的，我覺得矽谷最厲害的地方就是在這裡。
是啊。
好，ok。立法院當然都有狀況，今天其實因為有逐字紀錄，大家就是想到什麼，就是想要做的，或是各界幫忙的部分就盡量講出來，然後我們會有十個工作天的時間，在線上進行修改，所以也不用怕講錯話，我希望我們先聽一下目前這個系統整合計畫初步的構想，我們再來進行實質討論，好不好，謝謝。
好，謝謝。
好，一共九點，不曉得大家還有什麼想法，就可以一個一個來。剛才派工那個已經一定程度上說明了，其他就請這邊。
請說，我們從第十個開始。
好，還有其他問題嗎？我們可以統問統答。
好，都是非常好的。
OK，14項，還有第15項嗎，歡迎盡量提出（笑）
沒有，那我們就一個一個來處理。看看是要什麼順序都可以。
我知道推送部分，NCDR之前有一些經驗。資安這邊其實我剛剛聽到的是說，我們首先整個公共民生物聯網會有一致的資安標準。
這個其實遵循它就好，沒有特別需要做什麼。
另一個就是說我們要確保IPTV來的訊號，我們要假設他是不可信的，甚至是惡意的。所以如果是IPTV接近來的資料有任何不是完全，CSV這種不太容易攻擊的資料，他只要有任何可能進入我們執行的Pipeline。例如：他直接給MP4或是串流，你要假設他裡面全部都是木馬，是想要緩衝區溢位，不是什麼善意的東西。
在這樣的情況下，我們在建置的時候，接的關卡就要進行清洗，或是一開始就明確定義格式，讓他沒辦法藉此攻擊。這是第一項我聽到的事情，這個實作上如果有困難或是覺得這個問題本身需要重新提出或是需要調整的話，可能就要提出來；不然的話，這個就會變Action Item。
你們有沒有偏好的格式？
事實上MotionJPEG技術夠簡單也已經非常久了，要進行資安攻擊的機率比較低。
新的codec要看用什麼方式來轉換處理。如果這邊已經有偏好，我們接下來工作的時候就把介接的Hub當作工作項目的一部分。如果內政部或國網可以運行，反正哪裡有CPU哪裡運行，我覺得這是很好的具體建議，這樣也減少IPTV如果什麼Codec都收，如果他突然丟有問題的東西出來，我們也很難做滲透測試，因為他的組合太多了，我們至少把格式的部分做控制。
我沒有記錯的話，MotionJPEG就是一連串JPEG，我覺得JPEG那個Codec應該還好。它主要的問題是頻寬要求非常重，因為他沒有做現代的這些壓縮，但是如果我們每次看的時候就只是稍微監看一段時間，感覺上應該是還好，但是比較沒有資安顧慮。
像剛剛蘋果發表會的那種Demo，應該不會實際在這個系統上出現，我們要的只是看雨多大，橋有沒有斷掉，他等於是很多張照片，一秒一張照片，我真的覺得還好。當然還是要一些注意，但是他的攻擊層面滿小的。如果沒有別的我們1就這樣子。
接下來2就是查核點。先從特別預算拿下來，再從招標開始算，這個具體是幾月？
瞭解，剛剛說明年汛期上線第一版的時候，意思是幾月？
五月一號，所以基本上大概有半年左右的全部作業時間，但是還包含測試，所以實際開發其實並不長。只有三、四個月，以第一期來講。
瞭解，不過最近不是有一個文化說，在汛期中不會上版。
所以說就是五月一號，最多五月底，看到的就是一整年的版本。概念是這樣子，這個查核點相對是容易寫的。
就是說明年五月來不及上的話，其他哪一些是逐步的測試驗收，我們等汛期過去後明年年底驗收的項目有哪些，這些項目要Grouping一下。就是說如果哪些已經知道不可能明年五月完成的，至少那些是切出來，大家比較不會有不合理的期待，大概是這個意思。
如果這樣ok，查核的時程就分成確定五月一號可以上的，還有不能上的，還有在之間的。後來的後續規劃這邊已經想到，但事實上會超過第一期特別預算執行的時程的話，那個就是Nice to have或是For the future。
那接下來3：關於歷史相關的資料。圖裡面有所謂的資料產品，已經策展過的某個個特定災駭的報告。就是發現這次發生災害他看起來就想之前的某兩個，然後它就自動提供一些分析報告。請說。
所以他的運用基本上是我開另一個電腦放在這邊，那個螢幕上面顯示上次某個颱風來的實際情況，或是把事件簿開在那邊。但是如何縱整，目前是我要自己想到去看某一次的時間回溯，另一個是說掉出來的時候他跟目前的關係是人腦在判斷，是工人智慧，不是人工智慧（笑）。
剛剛這個葉副主要問的就是這兩個，我看一些雨量資料，系統就自動建議一些資料跟過去的某幾要比較相像。
第二個是說，事件簿調出來的時候是不是可以加一些自動的分析說，當時發生的事情做的判斷，跟現在的哪些比較相近。其實都是一些推薦系統，不是說這個調出來就是一定要照著做，這樣就完了。
而是只是說把最相關的，不管是事件或是判斷，把它調出來，這不曉得有沒有做過類似的。
其實不管是人工智慧還是工人智慧，使用者看到的界面是一樣的。我們在做使用者體驗研究的時候有Wizard of Oz 綠野仙蹤法，就是看起來像人工智慧，事實上是人在幫忙選。
至少在進行開發或測試的時候有人在假裝是人工智慧幫你選，這件事情會不會有幫助，如果沒有什麼幫助，這件事就保持在人工作就好。如果發現每次都有幫助的話我們就稍微投資一點時間或一些演算法下去，去把這部分自動化。只是探索，沒有要馬上變成 Machine learning，這樣可以嗎？就稍微往這方向想。
第4個是說，縣市政府根據區域差異都會有決策流程，包含地方的一些系統，泛指工人跟人工智慧的部分。
想問的是：API都已經接出來了，是否有可能Survey一下縣市政府的決策流程，我們可以提供什麼決策服務？接到當地的決策系統，或是他們沒有開發系統的能量，我們這邊可以幫忙一些東西。
這部分我們請國發會已經通過了OAS3，國際標準組織Linux Foundation下周會正式頒布這份文件，我們也會參與後續的幾個開發。以後地方政府特別要求你們寫某個端點出來的時候，建議用這個方式把它寫清楚，開了什麼明管出來。
這樣其他地方政府就可以說我要跟他一樣的，但是加這個地方或減這個地方，這樣子未來大家才能夠有一致的討論空間，不然每個縣市政府都有一大本說明書，這樣其實比較難討論。所以這個之後也參考國發會與工程會頒布的那個「共通性應用程式介面」的規格進行客製化，我覺得比較好。
那地方政府我上次去聯席會議，他們講的另一個非常有幫助的部分，之前常常需要登打好幾次，因為不同部會跟系統需要不同格式，如果這邊有辦法做一些基本的格式轉換，或是格式沒辦法轉換的話，可以一次填這兩個連集到你們系統，你們再去作分流。
其實每次災害發生的時候，他們只要稍微減少一點重複登打力氣，他們就多很多力氣做實際防救災工作。這部分我們也把他列進去，如果需要跨部會協商，甚至包含欄位這些的，就隨時跟我說。這個原則來做第4點。
當登打有派工的時候，這個事項的追蹤是否有在這個系統做呈現？
不用等一下，現在就可以做DEMO(笑)。
我聽起來葉副的意思不只是這個東西RWD，讓他在手機上開得起來。而是Fundamentally是把這個東西也做成一個API，然後在手機上接那個API，在手機上進行繪製。即使一開始明年五月在手機上繪製還是跟這個差不多也沒有關係，但是以後某一個點上面，他可以用不同的方式做繪製，可能可以跟某知名叫車軟體一樣（笑） 。
至少他留下這個可能性。不是說明年五月就跟某知名叫車軟體一樣，至少我們前後端分離，是用結構化資料方式呈現在手持裝置上，可能明年五月還是只能畫成表格，這是無所謂的，但是要保留未來變成某知名叫車軟體的可能性（笑）。
所以這部分我想就是API First，這是一件事情。另為一件事情是目前登打是像追蹤，從你們中心人員以及被派遣人員，我們叫做User Journey，如果能夠趁這次規劃的機會畫出來，事實上可以請廠商畫出來。目前有API，User Journey長得跟現在一樣沒關係，我們未來要做優化的時後，才有優化的起點，比較不會辦現有的系統綁住。大概是這樣。
那接下來就是教案的部分，剛剛也規劃了一些經費，這樣剛剛具體的建議是說，實際上請K-12的朋友們，或是中學生甚至小學生，來參加這個規劃，也包含目前民間對防救災感興趣的朋友，是不是也把他們邀進來。
接下來也是現有的，EMIC的功能，避難所的管理，是不是也是比照剛才知名叫車系統的規劃來做（笑）？
這個系統是今年才開始可以用？
親友協尋系統。
