電氣火災在火災事件中所占的比例呈逐年上升的趨勢，在電氣火災的防控工作中，遠程智能監控系統將發揮著重要的作用，能夠從源頭上抑制電氣火災的產生，保證人身和財產的安全，而在智能監控系統的應用上，也需要對設備、技術手段進行不斷的更新。
1 電氣火災智能監控系統工作原理與特征
1.1 系統工作原理
在電氣設備運行的過程中，諸如電流載荷過大、溫度驟升、功率過高等原因都會引發故障的發生. 當出現此類故障而導致電弧、漏電等探測器以及剩余電流傳感器等設備所檢測到的閾值超出了原本預設的范圍值時，終端探測裝置利用電磁場感應原理以及溫度效應的變化，自動從現場采集該區域內的數據參數以及狀態信息，再將所收集到的信息、數據傳送到電氣火災監控探測器之中，經過放大、A/D 轉換、CUP 對變化幅值進行分析和判斷， 檢測出異常的閾值，與報警預設值進行對比，一旦有超出預定值的情況，及時發出報警信號。與此同時，將數據、報警信息、狀態信息等傳送到電氣火災監控器做更深入的分析. 當從所采集到的信息中判斷存在火災隱患時，會將這一信息傳送至監控主機， 通過報警器、指示燈等設備發揮其警示作用 。
1.2 系統特征
電氣火災智能監控系統具有以下特征 :(1) 為了能夠使用戶更加方便地將電氣的運行控制在安全范圍以內，智能監控系統通過對電氣終端進行實時監控，以數字化的形式將現場相關數據參數加以呈現 ;(2) 通過物聯網技術進行智能遠程監控，能夠有效降低人力巡查的成本. 系統在檢測出存在火災隱患時，將通過無線互聯的方式將具體信息數據傳輸至用戶終端，提升管理效率的同時避免重大火災的發生 ;(3) 用戶可根據大數據智能平臺提供的可視化圖表，對安全指標進行全面的監控，并在發現異常的情況下提供報警通知等服務 ;(4) 智能監控系統實行實名認證，對非認證用戶的訪問有嚴格的限制，能夠確保用戶信息安全，同時緩存相關數據，避免因網絡因素、設備故障等原因造成數據的丟失，確保系統的安全性與可靠性。
2 電氣火災監控系統設計分析
2.1 剩余電流式電氣監控設備
第一，密集母線回路位置，關于線路較長的電力輸送，由于密集母線槽并不是標準件，所以其絕緣材料和組裝形式不能為整體質量奠定保證和基礎。所以在密集母線回路實際使用過程中， 經常會不斷出現接頭位置絕緣不足現象，進而會導致整個地鐵之中出現一系列嚴重問題，那么則可以使用剩余電流檢測設備對其絕緣基本狀態進行實時監測和動態分析，能夠對整個地鐵起到有效預防火災的效果。
第二，剩余電流檢測設備的具體使用，可以對電纜剩余電流進行最有效的監控，在整個過程中不需要安裝進線回路以及母聯回路等，單獨一個剩余電流檢測就能夠起到很好的火災防火作用。
第三，對區間隧道水泵供電回路進行合理檢測工作中，需要對剩余電流檢測進行增設基本工作，由于水泵電纜長時間處在通電情況下，并且自身存在安裝環境不好以及溫度高等各種問題， 因此使得絕緣設備會在長期運行之中降低自身的絕緣能力，絕緣受損情況出現的比較多，所以在此位置上需要添加多余電流設備進行工作，進而能夠起到最好的電氣火災監控作用。
2.2 電氣火災監控探測器
借助這些基本設備對收集到的真實信息進行最有效的判斷和分析，能夠對周圍數據進行整合，并實現集中監控工作。數據集中監控設計一般是因為監控主機和其他不同監控單元形成的主要內容，一般適用于小型系統監控工作的實現。監控主機數據數據處理功能，并且需要整合設備具有非常強大的數據分析和處理功能，可以對各項數據具有良好的數據處理功能，因此能夠看出其也可以使用在大型系統處理工作之中。借助不同監控單元對檢測器進行合理檢測和連接工作，并且能夠對地鐵進行全面集中的管理，對整個地鐵正確運行具有一定價值和作用。
2.3 電氣火災監控平臺
2.3.1 服務端
服務端由微服務架構組件和微服務應用模塊組成。微服務架構組件由 SpringCloud 提供，主要有 API 網關、服務發現以及負載均衡 ( 圖中未畫出 )、服務容錯保護等，構成微服務架構應用模塊開發實現的基礎。各模塊使用 SpringBoot 框架實現。
MQTT、CoAP 以及 HTTP 服務實現與探測器的通信功能。若探測器使用 HTTP 協議則需要先經過 API 網關，再由 HTTP 服務模塊進行處理。設備服務提供探測器最新上報數據、歷史數據信息查詢等服務; 信息通知服務主要負責異步給用戶發送報警信息通知等服務 ; 用戶服務提供用戶登錄和探測器管理服務。
2.3.2 數據庫
使用單一的關系型數據庫，受限于硬盤讀寫速度和數據庫本身的性能，易造成效率低下，難以滿足高并發訪問的需求。例如當用戶查看設備的最新信息時，如果每次都直接從 MySQL 數據庫中獲取，MySQL 的搜索引擎需要先根據設備 ID 從硬盤讀取該設備所有的數據信息，然后根據時間字段降序或者升序排序，取出第一條或者最后一條才能得到最終需要的數據。這種方式在用戶訪問量大及設備多的情況下，將對數據庫造成巨大壓力，同時服務器的響應時間延長也會影響用戶體驗。相似的問題也會出現在用戶查詢設備的歷史數據時。為此，平臺使用非關系型數據庫Redis 作為補充，以減輕關系型數據庫的壓力，提高平臺的處理速度和并發能力。此外，在分布式系統中的用戶單點登錄、本平臺中存儲隨機密碼的短時間定時存儲業務中，非關系型數據庫也具有更好的適應性。
2.3.3 客戶端
(1) 瀏覽器客戶端
前端頁面部分，使用 AJAX 技術 ，通過在后臺與服務端進行少量數據交換，在不重新加載整個網頁的情況下，實時更新設備上報信息。數據可視化使用 Datatables 表格插件和 Hightcharts 圖表庫。
(2) 移動端 APP
為實現用戶隨時隨地查詢電氣火災監控探測器的相關信息狀態的需求，開發了基于 Android 的移動端 APP。采用經典的 MVC 開發架構，分為業務層、視圖層和操作層。業務層處理各類應用業務，完成網絡請求、數據分析、數據處理功能; 視圖層分為可視視圖和隱藏視圖，主要完成手機端與用戶的交互和應用界面的更新替換; 操作層用來分離業務層和視圖層的聯系，降低程序的耦合，使應用更加健壯，同時為后期維護做準備具體，具體實現功能與瀏覽器端類似。
2.4 智能傳感分析
隨著現代網絡科技的發展，現場探測器具備智能傳感功能將是智能監測領域的一大發展趨勢. 要想充分實現設備智能化這一研發定位，實現智能監測系統網絡化、數字化的服務方向，需要通過智能模塊與常規傳感器進行有效集成的方式，監測現場參數的智能感知，結合溫度探測、剩余電流探測器等，研發出綜合性較強的智能探測器. 依托于 RTOS 軟件平臺、ARM 嵌入式硬件平臺，將傳感器的參數進行采集與發送. 同時，建立專業的知識經驗庫，結合實時的報警信息來判斷故障的類型、程度、發生原因、具體方位等，并制定出有效的解決策略. 智能分析技術可以提供智能故障診斷、故障趨勢分析預測等功能，通過曲線走向來了解、掌握故障前后設備的狀態變化，并結合數據進行故障的原因分析。
總之，在地鐵之中要高度重視電氣火災監控機制的實施，對周圍可能出現的一切事物等進行詳細分析，制定相對應機制，針對整個電氣火災監控系統設計、自身存在的特點、以及應用進行深入分析，使其可以在地鐵之中充分發揮自身的價值和作用，推動整個地鐵事業的發展。