第三章 極早期火災感知
第二節 燃燒實驗規劃
承蒙內政部建築研究所的邀請，本計畫有幸與其他相關防火計畫案同時進行室內
H2S+CO.csv
Select Columns in Dataset
Clean Missing Data
Select Columns in Dataset
Split Data Linear Regression
Training Model
Score Model
Evaluate Model
模擬燃燒實驗，在此實驗中，預計將蒐集真實燃燒火場室內環境數據與真實感知測試，
透過規劃研究發現，可藉由內部多元感知模組來感知現場狀況，傳遞即時資訊，再經 由系統式整合，給予主系統各種輔佐判斷之相關資訊，將各種狀況發生時知感測紀錄 資訊，儲存置資料庫並加以上傳至雲端系統，以利後續人工智慧演算工程運算。「複合 式人工智慧避難引導系統」是一套經由物聯網平台結合各方數據再透過演算法計算出 預期成果的早期火場無人斥候系統。本系統整合眾多終端物聯網設備，透過多元感知 設備運作獲取所需資訊，本研究預期使用物聯網平台 IoTtalk 彙整溫度感測器與多類型 之氣體感測器並與藍牙定位裝置，透過平台加以分門別類不同的感測數據，將資料做 儲存，傳入至智慧型避難系統，配合隨時更新的感測資訊，進行即時性的演算。
壹、智慧感知
環境感知模組為本系統最不可或缺的一環，扮演系統演算的重要依據，在計畫中 我們測量環境中的溫度與各氣體數值，追蹤這些感知裝置的數值變化，依據這些測量 的數值變化量，讓系統對於這些異常數值給予示警，所以當各感知模組設置完畢後，
感測器便開始回傳場域資訊至物聯網平台，倘若場域發生異常時，回傳之數值將會使 監控系統偵測到問題，進而觸發避難程序。
一、多元感知模組
多元感知模組包含諸多環境感知設備，以及上述提及之 Arduino 載板與由樹莓派 為主的數據蒐集叢集系統；傳遞資訊的氣體感測裝置皆透過 Arduino 主板提供運作所 需電源，溫度感測則另外供電，兩者皆經由 ZigBee 2.4G Module(AppsBee RO)外接模 組進行資訊傳輸，設定 Baud Rate 至相同數值，使其得以進行資訊傳遞。所使用之感 測器經討論後，使用以下對於火場數值蒐集較有觀測價值之項目，有以下幾種：
1. Multichannel Gas Sensor
經由 USB 連接線提供主板電源並透過 zigbee 擴充板提供 sensor 5V 電力；主板至 感測器連結為一條電源線、一條接地線與兩條類比訊號線(圖 3- 3)。
第三章 極早期火災感知
圖 3- 3 Multichannel Gas Sensor 實際連接圖 (資料來源：本研究自行繪製)
2. MQ-136 H2S(硫化氫) Sensor
經由 USB 連接線提供主板電源並透過 zigbee 擴充板提供 sensor 5V 電力；主板至 感測器連結為一條電源線、一條接地線與一條類比訊號線(圖 3- 4)。
圖 3- 4 H2S Sensor 實際連接圖 (資料來源：本研究自行繪製)
3. CO Sensor
經由 USB 連接線提供主板電源並透過 zigbee 擴充板提供 sensor 5V 電力；主板至 感測器連結為一條電源線、一條接地線與兩條數位訊號線(圖 3- 5)。
圖 3- 5 CO Sensor 實際連接圖 (資料來源：本研究自行繪製)
4. CO2 Sensor
經由 USB 連接線提供主板電源並透過 zigbee 擴充板提供 sensor 5V 電力；主板至 感測器連結為一條電源線、一條接地線與兩條數位訊號線(圖 3- 6)。
圖 3- 6 CO2 Sensor 實際連接圖 (資料來源：本研究自行繪製)
5. PT100 溫度感測器
由左方 24V 電源提供電力，透過電源線輸出至溫度轉換器，並與 PT100 溫度感測 器連接兩條訊號線，主板方面則予以一條接地線及一條類比訊號線(圖 3- 7)。
第三章 極早期火災感知
圖 3- 7 溫度感測器實際連接圖 (資料來源：本研究自行繪製)
數據蒐集叢集系統組成為 Raspberry Pi 3B +、可連網之行動或無線網路、Arduino UNO R3、ZigBee 2.4G Module(AppsBee CO)，將回傳資料運用 Raspberry Pi 中的 Python 方式進行資料上傳，將所有資訊傳回至 IoTTalk 中，其實際連接圖如圖 3- 8。
圖 3- 8 資訊叢集協調端實際連接圖 (資料來源：本研究自行繪製)
本研究使用以上 5 種感測裝置作為資料蒐集的媒介，其中 Multichannel 目前使用 來蒐集 NH3、NO2 等氣體，其餘皆針對特定物質做數據接收。由感測器連接 Arduino 底板，並由 Zigbee 擴充板傳輸，再由連接至樹莓派的 Zigbee 做接收，接收的數據使用 樹莓派 4G 模組如圖 3- 9，使用網卡方式將資料上傳至 IoTtalk 平台，同時儲存到資料 庫。
圖 3- 9 樹莓派 4G 模組連接圖 (資料來源：微雪百科)
本研究將該系統所使用之工作版、感測器與其相關設備之相關資 訊整理為感測元 件一覽表如表 3- 1 所示，建構之模組整理表如表 3- 2 所示。
表 3- 1 感測元件一覽表
工作溫度 Arduino uno R3 -40～85℃
Zigbee 2.4G 擴充板 -40～85℃
Multichannel Gas
氣體感測器 -10～50℃
CO 氣體感測器 -20～45℃
CO2 氣體感測器 0～50℃
MQ136 H2S 氣體感測器 -10～50℃
PT100 溫度感測器 -200～420℃
溫度 24V 電源轉接 -20～80℃
溫度轉換器 -20～85℃
樹莓派 3 B+ -40～85℃
樹莓派 4G 擴展板 (SIM7600CE)
-30～80℃
(資料來源：本研究自行繪製)
第三章 極早期火災感知 表 3- 2 感測模組一覽表
測量範圍 通訊模組(Arduino uno
+ AppsBee)
溫度感測模組 0℃～300℃
CO 感測模組 1~1000ppm CO2 感測模組 0~5000ppm H2S 感測模組 1~200ppm
Multichannel Gas 感測器(組) 能或是特徵來做分類，訂定物聯網設備功能(特徵) (device feature，DF)做為特殊的輸入 或是輸出功能(capability)，將擁有偵測功能的穿戴裝置稱為輸入功能(input device feature, IDF)，將擁有顯示等功能的穿戴式裝置稱為輸出功能(output device feature, ODF)。
一、IoTtalk
IoTtalk 系統是一個建構於分類設備功能 (device feature) 特徵概念的物聯網設備
圖 3- 10 IoTtalk 輸入、輸出設備功能圖 (資料來源：本研究自行繪製)
二、平台架構
IoTtalk 可稱為物聯網設備特性管理系統，主要可分成選單(menu bar)、圖形布局 視窗(Graphical Layout Window)以及管理視窗(Management Window)三個部分。圖形布 局視窗會顯示物聯網設備連線情形，連結成功的設備稱之為連線物件(connection object )。管理視窗讓使用者可以設定圖形布局視窗中的設備功能、連線、以及對應之 函數 (Lin, Lin, Huang, Chih, & Lin, 2017)，其設備連接範例如圖 3- 11 所示。
第三章 極早期火災感知
圖 3- 11 IoTtalk 設備連接圖 (資料來源：本研究自行繪製)
當使用者選擇欲使用的物件時，圖形介面會從資料庫中抓取這個設備模式中所有 已註冊的設備。假使相同的設備模式有好數個設備已註冊至 IoTtalk 系統平台，則每個 註冊的物聯網設備，圖形介面都會在管理視窗中產生一個已註冊的設備列表。完成註 冊後 IoTtalk 系統會將實際將設備連結至所指定的設備物件，後續圖形介面將可以不經 過選擇的程序，直接取代該物件，連同取消連結時也亦同，註冊成功如圖 3- 12。
圖 3- 12 IoTtalk 設備註冊圖 (資料來源：本研究自行繪製)
平台中設備相互連接的部分，一個輸入設備功能(IDF)可以經由圖形布局視窗中一 個稱之為連結物件(join object)的小圓圈連接至輸出設備功能(ODF)。舉例一條連結只包 含一個輸入功能設備則稱之為單一連結(single join)，如果一條連結包含多個輸入功能 設備則稱之為多重連結(multiple join)，對於連接至同一個連接點的多個輸出設備功能 (ODF)而言，輸入設備功能(IDF)對所有的輸出設備功能所造成的影響都是相同的，所 以即使有多個輸出設備功能(ODF)連接至同一個連接點，到最後只有一個輸入設備功 能(IDF)連至此一連接點，仍然可稱為單一連結。
本計畫的燃燒實驗應用研究中，使用物聯網平台 IoTtalk 連接目前所規劃的物聯網 終端設備，將其所有設備進行設定，在感測裝置運作時，能以系統化方式進行管理，
輸入輸出的部分經由分門別類的特性規劃，經由網路傳輸就可以傳送或接收來自物聯 網設備的訊息。
三、數據儲存
在 IoTtalk 運作中的感測裝置，其感測出的數據結果，可從伺服器透過物聯網平台 進行資料的下載，並根據特定之需求分別處理不同單元進行感測裝置的數據下載，在 儲存方面則可選擇採用 linq to SQL 的整合資料庫語言，藉以提升資料庫在儲存時的效 率，可避免所需資訊在蒐集時發生儲存不即時而造成遺失的狀況發生。
第三章 極早期火災感知
參、資訊蒐集系統
數據蒐集型態，目前預計由下方標示的 21 個字元所組成的資料型態，進行統一的 資訊管理規劃，使各項數據依照名稱或類別的不同，都有相對應的表示方式，以此方 式彙整所需數值，並進行數據的儲存以及上傳，彙整資訊型態格式如圖 3- 13。
圖 3- 13 數據型態表示圖 (資料來源：本研究自行繪製)
一、感測器資訊傳輸
感測器開始運作後，如有異常狀況發生將會啟動重新開啟程序，直到異常判斷消 失為止，正常執行時會啟用環境感知功能，進行各類型環境探測資訊蒐集，並由 ZigBee 進行資料的外部傳輸。直到電源關閉得以結束，其流程圖如圖 3- 14。
圖 3- 14 感測器資訊傳輸流程圖 (資料來源：本研究自行繪製)
二、樹莓派資訊傳輸
樹莓派開始運作後，將開始確認網路連線狀態以及硬體運作狀況，如有異常會將 其重新啟動，直到能正常由 ZigBee 模組接收另一端傳輸過來的資訊為止，將資訊依照 其型態特徵，給予資料接收時間排程，依照資料先進先出的結構概念，進行佇列儲存，
再來進行 IoTtalk 物聯網平台的連線確認，如可順利進行連結，便可將以上資訊進行唱 傳，便可在進行下一階段之資訊接收，直到電源關閉，其流程圖如圖 3- 15。
圖 3- 15 樹莓派資訊傳輸流程圖 (資料來源：本研究自行繪製)
三、伺服端資訊傳輸
伺服器端透過物聯網平台 IoTtalk 進行資料的下載，並進行資料儲存，其步驟如圖 3- 16 所示，伺服器程式會透過 IoTTalk 平台下載資料，為了讓平台與資料擷取的叢集 端能夠順利將資料回傳至伺服器，必須要在伺服器程式中以佇列方式來進行資料接收，
將所有的資料逐一接收並且排入佇列當中，讓資料能夠以先進先出的方式來處理所有 的資料以防遺漏，而伺服器程式另一端則是來處理佇列資料並將其存入資料庫，會將 資料中的相關數據進行切割，並將資料所夾帶的時間戳記進行資料庫時間格式進行轉 換，以取得資料感測時的時間，並透過 SQLtoLINQ 技術將資料以模組形式逐一加入 資料列表中，並累進數量至定量後一次存取資料表，以降低資料庫儲存之佔據以及記 憶體的釋放，以提升伺服器端應用程式的效率，而伺服器端執行是一個無限型的迴圈 方式進行執行，只要有數據從 IoTTalk 平台中被下載就會進行處理，直到伺服器被關 閉為止，若被關閉則伺服器會完成執行任務結束程式。