基于物聯網和Web技術的可視化火災報警系統設計與實現

關鍵詞：物聯網；Web技術；可視化；火災報警系統；移動應用

0 引言

火災已成為一種頻發性災害，對經濟發展和社會穩定構成直接影響，嚴重威脅人民生命安全[1]。隨著城市建設規模不斷擴大，火災發生概率隨之上升[2]。火災報警系統在保護生命和財產安全方面發揮著至關重要的作用。傳統火災報警系統雖然在一定程度上起到了火災預警作用，但仍面臨諸多挑戰，如信息傳遞滯后，無法準確快速掌握火災時間、地點、實時火情等信息；缺乏統計功能，不利于管理部門進行災后分析和預警。

現有研究已探索將單片機、視頻識別技術和圖像識別技術應用于火災報警系統[3-5]，但這些系統存在功能單一、缺乏可視化、無法遠程監控等局限性。為彌補這些不足，本文設計了融合物聯網技術與Web技術的火災報警系統，實現了火災的實時遠程監控和可視化報警功能，為火災防控提供了新的智能化解決方案。下文將從可視化火災報警系統的系統需求分析、功能實現、系統測試三個方面進行具體說明。

1 系統需求

1.1 功能需求設計

為提高火災報警系統的智能化和可視化水平，需要在城市中布局火災環境檢測設備，并將檢測數據進行集中收集、整理和分析，通過可視化方式呈現給用戶。通過這種方式，用戶能夠直觀地了解當前火災風險情況，及時做出應對措施。因此，系統應具備以下功能：

1） 實時監測環境動態。通過與各類環境監測設備的聯通，系統可實時獲取各個檢測地區的傳感器數據和位置信息。

2） 將各傳感器數值、經緯度等信息以可視化形式呈現在系統界面上，使用戶能夠清晰了解各地檢測數值及報警情況，以便在火災發生時及時采取相應措施。

3） 具備火災任務管及時發布滅火任務，使消防員能夠根據可視化信息第一時間到達現場，并在處理完危情后及時更新火災任務狀態。

4） 除火災動態監測和任務管理外，系統還提供其他功能。如為消防部門提供歷史火災數據的統計分析報表，幫助其更好地找出潛在火災風險，提前進行預警。同時，系統還具備公告管理功能，用于發布重要通知。

根據以上分析，可視化火災報警系統應由物聯網采集模塊、可視化管理模塊、數據中心三大模塊組成，系統整體模塊如圖1所示。理功能。當出現火災報警時，

單片機電路配置有定位模塊和環境檢測模塊（包含煙霧氣敏傳感器、溫度傳感器、二氧化碳濃度傳感器），并在單片機中設置報警算法。單片機外接網絡模塊，將各傳感器數值、定位數據、報警狀態等數據上傳至阿里云平臺。由于此過程在傳統火災報警系統[6]中應用廣泛，在此不再贅述。

可視化管理模塊是本系統的重點，后臺從阿里云平臺實時獲取各個傳感器數值及GPS定位數據，并將其保存在數據庫中。系統結合高德地圖API，將這些數據顯示在Web前端的地圖上，實現數據可視化。為實現消防員出警時的可視化功能，系統增設Android App端，消防員可通過手機App查看地圖，以便更快捷地到達現場，并在App上更新火警任務狀態。此外，Web系統端還具有火警統計和管理公告功能，便于消防指揮中心對火災報警進行管理。

1.2 系統用例圖

根據1.1節分析，可視化系統主要包含管理者（消防指揮中心）和用戶（消防員）兩個角色。管理員通過Web端可進行公告管理和任務管理。在“公告管理”頁面可添加、編輯公告；在“任務管理”頁面可進行任務查看和任務統計。用戶打開App端后，可顯示“主頁”“公告”“我的”三個頁面。在“主頁”中可查看火災任務列表并進行危情處理，在“公告”頁面可查看Web 端下發的公告，在“我的”頁面可修改個人信息和密碼等。管理員和用戶角色的用例圖如圖2所示。

1.3 關鍵技術

通過分層架構（前端層負責用戶界面和交互邏輯；后端層負責業務邏輯和與數據庫的交互；數據庫層存儲系統所需的所有數據）、模塊化開發等模式，結合前端框架、后端框架、數據庫框架和移動端框架的選擇，可以實現一個高效、可靠和可擴展的火災報警系統[7]。

選擇Vue作為Web前端框架，用于構建用戶界面和交互邏輯。Vue體積小，加載速度快，適合開發輕量級的應用。在Android開發中選用Kotlin語言，這是一種基于Java虛擬機的靜態類型程序設計語言，Kotlin 不僅可以在Java虛擬機上運行，還可以編譯成JavaS? cript。系統使用OkHttp+RxJava 的組合作為Android 和Java開發的工具集，用于處理異步HTTP請求和響應。將OkHttp和RxJava結合使用，可以將OkHttp的異步HTTP請求轉換為RxJava的Observable對象。選擇WebStorm作為前端開發工具，WebStorm是一款功能豐富的Web開發環境，該開發環境為開發者提供了許多簡單實用的工具和特性，提高了開發效率和代碼質量。WebStorm 具有豐富的代碼編輯功能，支持HTML、JavaScript等多種編程語言，并且具有語法高亮功能，這樣可以讓代碼更加易讀易懂。后端框架采用SpringBoot，SpringBoot 框架內嵌了Tomcat、Jetty 和Undertow服務器，并且可以自動化配置第三方庫，減少了開發人員的工作量，提高了程序的開發效率。后端開發工具選擇Idea，其提供了一個功能強大的代碼編輯器，支持智能代碼助手、代碼自動提示、代碼補全等功能，大大提高了編寫代碼的效率。數據庫則選擇MySQL，它是一個關系型數據庫，具有穩定、高效的數據存儲和查詢功能。

1.4 數據庫設計

在系統開發的整個過程中，數據庫設計是至關重要的環節，數據庫具備靈活的數據操作能力，包括添加、刪除、修改和檢索火災數據、用戶信息、地址定位和處理情況等數據庫的信息，從而確保系統能夠迅速響應用戶的信息需求。

本系統數據庫中包含user表、task表、notice表3 張表。其中user表用于存儲用戶和管理員的賬戶信息，存儲用戶的基本信息和權限設置。主鍵“用戶ID”是int類型，該類型通常與索引一起使用，以提高數據的檢索速度。為保證實體完整性，user表中的“用戶ID”“賬戶”“密碼”均不可為空。“訪問權限”用于區分普通用戶和管理員用戶，以保障系統的安全性。user 表的詳細定義如表1所示。

task表用于存儲火情任務信息，記錄從阿里云平臺獲取的火情數據以及在App端進行危情處理后更新的數據。主鍵“任務ID”采用int類型，不可為空；外鍵“用戶ID”為負責處理火情的消防員用戶ID；“報警狀態”采用布爾類型變量。task表的詳細定義如表2所示。

notice表用于存儲公告信息，主鍵“公告ID”采用int類型，不可為空；其他屬性采用varchar類型，支持最大長度達255個字符，適合存儲長度可變的文本信息。notice表的詳細定義如表3所示。

2 可視化火災報警系統功能實現

2.1 系統總體架構

系統采用分層架構，包括前端用戶界面、后端服務器和數據庫管理三大部分，系統總體架構如圖3所示。前端用戶界面分為Web 界面和Android App 界面，分別實現管理員（消防指揮中心）和用戶（消防員）的功能需求。用戶通過Android App和PC機Web頁面訪問系統，前端網絡請求通過OKHttp、HTTP、Ajax 發送至后端，后端通過與MySQL和文件系統的交互完成相應的業務請求和處理，并采用SpringBoot框架進行開發。系統中的實時火情數據來源于硬件采集設備，單片機將環境傳感器采集的數據通過網絡模塊上傳至阿里云平臺，后端服務獲取阿里云平臺數據并保存至數據庫。整個系統的運行需要高德地圖SDK和阿里云物聯網SDK的支持。

2.2 數據采集

數據采集模塊硬件組成如圖4所示，單片機模塊與外圍傳感器、GPS、傳輸模塊之間使用Urat串口傳輸協議，傳輸模塊與阿里云平臺通過無線MQTT協議傳輸。

阿里云物聯網平臺上注冊賬號并創建產品后，即可生成AccessKeyID、AccessKeySecret、ProductKey 三元組信息[8-9]。在產品下添加本系統所需要的物模型，包括二氧化碳濃度、煙霧濃度、溫度、GPS數據、報警狀態等信息。物模型是真實硬件設備到數據表示之間的映射[10]，例如二氧化碳濃度、煙霧濃度為單精度浮點數，與之相關的屬性為浮點數；報警狀態為Bool? ean類型，其中0表示無報警，1表示報警。

單片機模塊采用C語言編碼，編寫函數時首先使用三元組信息進行身份驗證，確保通信雙方的合法性；然后針對不同的ProductKey進行訂閱主題、發布主題，實現各傳感器現場數據與阿里云物聯網云平臺的數據傳輸[11]。MQTT傳輸層使用TLS/SSL安全協議，可以對通信數據進行加密，防止數據被竊聽和篡改。

2.3 獲取云數據

三元組信息也是使用程序訪問阿里云IoT的唯一認證，后端認證通過后，按照物模型的數據結構獲取各參數數值[12]，并保存到task數據表中。后端從阿里云平臺獲取數據是通過AMQP協議實現的，阿里云物聯網平臺已提供功能完備的SDK以便于快速開發。系統后端每間隔1分鐘向阿里云平臺發送消息，并從返回消息中提取出多個關鍵參數，包括二氧化碳濃度、溫度、煙霧濃度、經緯度、地址、日期、類型、描述、報警狀態等參數，并且將這些參數存儲在變量中，以供后續使用和處理。如果某個參數不存在，就會使用默認值（例如，如果“uid”參數不存在，就會使用“0”作為默認值）。然后，該代碼在數據庫事務中插入一個新的記錄到task表中，這個新記錄的各個字段的值就是之前從請求中獲取的參數值。

2.4 火災任務可視化

Android App可以調用高德地圖，將火災任務的位置以及火災信息展示在地圖上。地圖上還會顯示用戶自身的定位，用戶可以根據這兩個位置規劃出到達火災現場的最優路線。App的“附近地圖”頁面如圖5所示。

App端“附近地圖”中火災任務點功能開發所需的代碼定義了一個名為“load”的函數。該函數使用“HttpUtils.newInstance（）”創建一個新的HTTP請求實例，并添加了兩個參數：“zt”和“uid”。其中，“zt”的值為“待處理”，而“uid”的值則來自“LocalBeanInfo.user? Info？.id.toString（）”。接下來，通過調用“post”方法向服務器的“getRwList”接口發送POST請求。在請求成功時，會執行“onSuccess”回調函數，將返回的字符串數據轉換為“RwBean”對象列表，并清空地圖上的標記。遍歷各“RwBean”對象，為每一個“RwBean”數據創建一 個 MarkerOption 對 象 ，使 用 AMapUtil. convert? pToosLiatitoLnn，g同（）方時法將轉煙換霧經濃緯度度、二坐氧標化并碳存入濃度ma和rk溫erO度pt等ion相s.關信息存入markerOption.title，通過mapview.map.add? Marker（）方法將位置、數據信息顯示在地圖上。

2.5 危情處理

用戶到達現場并完成危情處理后，可以使用An? droid App進行火情狀態更新。用戶選擇案件編號，點擊編輯危情，危情處理操作界面如圖6所示。用戶輸入當前狀態（包括添加火災描述、火災圖片、添加自身定位）并提交，頁面中的所有數據會發送至后端，實現火災任務數據表的更新。

App端“危情處理”模塊開發所需代碼的功能如下：首先調用“super.onCreate（savedInstanceState） ”方法，設置布局文件為“activity_task”；再設置導航欄標題為“危情處理”；然后更新高德地圖定位客戶端的隱私協議同意狀態和隱私顯示狀態；接著設置導航欄右側按鈕的文本為“提交”；最后為導航欄右側按鈕設置點擊事件監聽器，當點擊時創建一個HttpUtils實例。之后添加請求參數，包括描述、圖片、經緯度、地址、任務ID和狀態，并發送POST請求至“updateRw”接口，同時實現成功和失敗的回調函數。成功回調函數顯示“提交成功！”的提示信息，并結束當前Activity；失敗回調函數則顯示錯誤信息的提示。

火情任務狀態更新數據流轉如圖7所示。當客戶端向服務器發送一個POST請求到“/updateRw”路徑時，后臺將執行以下指令：首先，此代碼從請求中獲取參數，并將這些參數存儲在變量中；然后會開始一個數據庫事務，嘗試更新名為task的表中與給定rwid匹配的記錄。該代碼將一些字段設置為從請求中獲取的值，包括日期、類型、描述、狀態、圖片、經緯度、地址、二氧化碳濃度、溫度和煙霧濃度。如果更新成功，則會返回一個表示成功的常量。

3 系統測試

3.1 測試環境

測試環境采用Windows 10操作系統、Chrome 瀏覽器、Android 14操作系統。

3.2 測試記錄

系統測試的核心目的是確保系統的各項功能都能達到預期的效果，包括火災報警的接收與展示、任務數據的收集與可視化以及用戶和系統的交互功能等多個方面。測試用例采用場景設計法，對上述功能進行測試并記錄。可視化火災報警系統Android App 端測試記錄和Web端測試記錄如表4、表5所示。

3.3 測試結果分析

經過嚴格的功能測試，本火災報警系統的所有功能模塊均可正常使用，且能保證穩定運行。因此，基于物聯網和Web技術的可視化火災報警系統已基本實現數據可視化、管理智能化的目標。

4 結論

針對當前火災報警系統的不足，本文成功設計了一個功能全面的火災報警系統。該系統以物聯網技術、Web技術為核心，是一款集實時數據采集、智能報警、環境數據可視化、危情處理移動化等特點為一體的新型火災報警系統。針對消防指揮中心的管理用戶和執行危情處理的普通消防員用戶，分別開發了Web可視化操作端和Android App可視化操作端。經測試，各項功能的實際測試結果均達到預期效果。系統技術成熟、可行性強，具有廣闊的應用前景。展望未來，該系統可在融入更加智能化的火災預警算法、與其他智能消防系統集成等方面進行新的探索，為保障人民生命財產安全做出更加顯著的貢獻。