王茹 ,李樸杰 ?,王亞康 ,胡又文
(1.西安建筑科技大學 土木工程學院,陜西 西安 710055;2.上海建科工程咨詢有限公司,上海 200032)
建筑是人類文明的標志,是人類社會發(fā)展的印跡,中國古代建筑的歷史更是源遠流長.由于時代久遠,我國明清之前的建筑大多已經(jīng)損毀,因此,當前我國存在較為完整的歷史建筑,大多為明清時期的建筑.明清古建筑為木或磚木結(jié)構(gòu),其主要建筑材料為木材,其耐火性差,一旦發(fā)生火災,大火往往難以撲滅.因此,對于古建筑火災的防治,應以預防為主,消防為輔.
對于古建筑火災的預防,以火災監(jiān)測為主要技術(shù)手段,早在2005年,劉國柱[1]提出以空氣采樣報警器探測空氣中煙霧濃度.然而探測器大多為有線網(wǎng)絡,需要在建筑內(nèi)走線,甚至需要開孔安裝,破壞古建筑結(jié)構(gòu).隨著無線通信技術(shù)的出現(xiàn),劉士興等[2]、Palma 等[3]均提出利用無線傳感器網(wǎng)絡進行探測器布置,可解決有線傳感器破壞古建筑美觀性和結(jié)構(gòu)的缺點.然而對于古建筑群而言,由于建筑數(shù)量十分龐大,導致所需探測器的數(shù)量更為龐大,僅依靠無線傳感技術(shù)已無法滿足其對探測器管理上的需求.因此,黃娟等[4]以ZigBee 無線通信技術(shù)傳輸探測數(shù)據(jù),以Android 客戶端為終端,將藏區(qū)古建筑群火災探測器與移動終端連接,搭建了移動端的App 平臺.然而移動端的App 平臺,有著管理界面小、大批量管理不易的問題,仍然需要一個計算機平臺進行大批量的數(shù)據(jù)管理,且對于海量數(shù)據(jù)的儲存、處理,也有一定的不足.除此之外,大量的探測器勢必會提高誤報的頻率,對于監(jiān)測數(shù)據(jù)的處理,也需要進行相關(guān)優(yōu)化.
針對此方面問題,本文提出一套基于xBIM 平臺二次開發(fā)、SQL Server數(shù)據(jù)庫管理系統(tǒng)的計算機火災智能監(jiān)測系統(tǒng).以火災危險源、建筑結(jié)構(gòu)為因子,設置出火災探測器的布置方案,再依據(jù)布置探測器情況建立數(shù)據(jù)庫,儲存和調(diào)用海量的實時監(jiān)測數(shù)據(jù),并應用迭代優(yōu)化后的Man-kendall 趨勢算法對其進行閾值處理,減少誤報,提高準確性.在監(jiān)測平臺中,可以實時查看各個探測器的狀態(tài),并在觸發(fā)閾值后給予及時的報警提示,提高了火災監(jiān)測的及時性、精確性,極大地方便了古建筑群火災安全的管理.
選擇適合的火災探測器是進行火災監(jiān)測的第一步,對于明清古建筑而言,火災探測器的選擇應遵循以下原則:
1)明清古建筑為木或磚木結(jié)構(gòu),其火災荷載密度[5-6]大,著火后火勢兇猛,因此無論從古建筑的文物珍貴性考慮,抑或從安全角度考慮,明清古建筑的火災報警最佳窗口期均應為燃燒的初期[7].
2)火災探測器的安裝方式應為無損安裝,避免打孔安裝方式對古建筑結(jié)構(gòu)的破壞.
3)火災探測器的體積不應過大,以免影響建筑美觀.
如今科技手段下,常用的火災探測器有感煙探測器、感溫火災探測器、火焰探測器以及圖像型火災探測器等,對其原理及優(yōu)缺點進行分析匯總見表1.
表1 各類火災探測器對比Tab.1 Comparison of various fire detectors
經(jīng)過對比分析,本文采用感煙探測器對明清古建筑進行火災監(jiān)控,原因如下:
1)明清古建筑為木或磚木結(jié)構(gòu),燃燒主要依靠大量的木構(gòu)件、木家具等.木材表面在受到持續(xù)的熱通量時,木材表面會隨著溫度升高而開始分解,產(chǎn)生大量的煙氣,隨著表面的熱解持續(xù)增加,會在傳遞熱通量的界面生成一個炭化層[8],炭化層具有一定的阻燃功能,發(fā)生的是陰燃,同時產(chǎn)生大量的煙氣,若在此時能探知出燃燒,便能及時控制火災,若發(fā)展到明火階段,即使發(fā)現(xiàn),也損失較重,撲滅也較為不易.因此,感煙探測器是較好的選擇.
2)感煙探測器多為點型探測器[9],其體積小、質(zhì)量輕、安裝方便簡單,對古建筑表面不造成損壞.
3)感溫火災探測器和圖像型火災探測器雖對環(huán)境適應性較好,但感溫火災探測器敏感度較低,現(xiàn)已較少使用,圖像型火災探測器適用于明火階段,對古建筑的保護不利.火焰探測器易受到環(huán)境的影響,誤報頻率高.
因此,綜合考量后,針對明清木結(jié)構(gòu)古建筑的自身特點,選取感煙探測器為最佳.
對于火災探測器的布置而言,有兩大影響因素,一是火災危險源,二是建筑結(jié)構(gòu).
1.2.1 火災危險源的影響
火災危險源是火災的源頭,對火災危險源實施監(jiān)測防范,能有效降低發(fā)生火災的概率,因此,人們通過危險源管理的方式對火災進行防控,如設置火災危險源登記臺賬[10]等.1949年以來,我國發(fā)生的大大小小古建筑文物火災上千起,損壞珍貴建筑、文物不計其數(shù),本文通過查找相關(guān)案例文獻、搜索相關(guān)新聞報道、查閱官方網(wǎng)站,共查閱到百余起古建筑火災事故,其中已查明起火原因的事故97起.
對這97 起古建筑起火原因進行了匯總分析,整理出11 種不同的火災危險源,以統(tǒng)計圖形式將不同火災危險源所占比例進行表征,如圖1所示.
圖1 火災危險源餅狀圖Fig.1 Fire hazard source pie chart
由圖1 中可以看出,古建筑起火主要原因為電氣老化或短路,殿內(nèi)燭臺、焚香或燒紙,亂丟煙頭,生活用火等.因此,在對火災探測器進行布置時,以當前古建筑的環(huán)境特點為對象、主要火災危險源為重點,做到重點位置重點部署.
1.2.2 建筑結(jié)構(gòu)的影響
火災在建筑內(nèi)的燃燒過程,是一個復雜的熱力學、流體力學、傳熱學和燃燒學過程[11-13],其熱氣流在建筑內(nèi)部的運動路徑,與建筑的結(jié)構(gòu)、可燃物位置、門窗位置(氧氣通道)均相關(guān),其共同構(gòu)成了建筑火災的發(fā)展過程.因此對于建筑內(nèi)部火災探測器的布置,應根據(jù)建筑結(jié)構(gòu)等實際情況進行.
對于明清古建筑而言,抬梁式與穿斗式木結(jié)構(gòu)是使用最為廣泛的兩種木結(jié)構(gòu)形式.這兩種木結(jié)構(gòu),如圖2 所示,在力學原理、木材用料上都截然不同.抬梁式木結(jié)構(gòu)是梁柱支撐體系,由多層的架梁和柱子傳受力,多用于北方地區(qū);穿斗式木結(jié)構(gòu)則是檁柱支撐體系,由檁柱直接將屋頂“頂起”,承受主要荷載,多用于南方地區(qū).
圖2 抬梁式與穿斗式木結(jié)構(gòu)Fig.2 Lifting beam frame and Chuan-dou frame
兩種木結(jié)構(gòu)都以木材為主要受力構(gòu)件,而抬梁式木結(jié)構(gòu)在木材用量上更是穿斗式木結(jié)構(gòu)的3.5倍[14].抬梁式木結(jié)構(gòu)多用于大跨度、大空間組合的官式建筑,而其恰巧為火災的燃燒創(chuàng)造了條件,猶如燃燒的爐子,有大量的木材,也有充足的氧氣空間.而穿斗式建筑多用于民居等空間較小的建筑,兩者在建筑材料、結(jié)構(gòu)形式、空間大小上,均不相同,在火災發(fā)生后的蔓延情況也不相同.
為將火災危險源及建筑結(jié)構(gòu)對火災事態(tài)的綜合影響可視化,本文以 BIM 技術(shù)、火災動力學模擬為手段[15-16],對兩個因素的共同作用進行模擬分析,以模擬出實際建筑環(huán)境下的最不利點,從而指導探測器的布置.PyroSim 是目前較為成熟的火災動力學模擬分析軟件,但其缺點是建立的模型較為粗糙簡單,如屋頂斜面、曲面的建模均難以實現(xiàn),這使得“建筑結(jié)構(gòu)”這一因素的影響難以突出.因此,本文以Revit作為精細化的建模工具,F(xiàn)bx 數(shù)據(jù)格式作為二者連接的橋梁進行建模分析.以某穿斗式木結(jié)構(gòu)為例,該結(jié)構(gòu)為三層穿枋結(jié)構(gòu),應用 Revit 建立該結(jié)構(gòu)下的三維模型,并導入至 PyroSim 中,模型見圖3.
圖3 穿斗式木結(jié)構(gòu)模型Fig.3 Chuan-dou frame model
圖4 煙霧模擬結(jié)果Fig.4 Smoke simulation results
模擬環(huán)境初始溫度為 20 ℃,網(wǎng)格單元大小為0.25 m×0.25 m×0.25 m,以殿中燭臺引燃木質(zhì)香案作為起火點.由于木結(jié)構(gòu)建筑火災荷載大,因此起火點設置為快速火,單位熱釋放速率為 611 kW/m2.對于感煙探測器的布置,重點關(guān)注模擬結(jié)果中煙霧的擴散情況.其模擬結(jié)果如圖 4 所示,由于設置為快速火,產(chǎn)生的熱煙氣在T=3 s 時,便上升至起火點上方第一層穿枋,隨后在T=25 s 時,在屋頂向兩側(cè)蔓延,集中于二層與三層穿枋之間.
隨后,煙氣沿兩側(cè)山墻順流而下,而隨著時間的推移,煙氣密度逐漸增大而開始逐漸下沉并從門窗通風處開始外溢.火災源在古建筑內(nèi)的位置因建筑的不同布局而具有特殊性.當古建筑內(nèi)部發(fā)生火災時,著火點產(chǎn)生的熱煙氣流隨時間流動的軌跡具有一定普遍性,即熱煙氣均是先由火災源處上升,升至屋頂結(jié)構(gòu)最高處時沿屋面結(jié)構(gòu)橫向散開,后隨著濃度的增強開始下沉.在探測器布置點位受限的前提下,若將感煙探測器全部布置于最低一層層架處,則及時“捕捉”到細小上升煙氣的概率較低.若將感煙探測器全部布置于頂層層架,則需至煙氣上升至屋頂且向四周蔓延開時方能捕捉火情,不具備及時性.二層作為煙氣穿越層,在火災前期不及一層的及時性,在火災后期不及頂層的普遍性.因此,既針對可預測性火災源在一層層架處進行重點布控實現(xiàn)及時性監(jiān)測,又在頂層層架處布置提高煙氣捕捉概率,實現(xiàn)“及時性”與“普遍性”相結(jié)合.在本文案例中,應在香案燭臺上方的第一層穿枋或斗枋上布置感煙探測器,在其余無火災危險源的地方,在第三層穿枋或檁處設置感煙探測器,這樣能夠最快速地發(fā)現(xiàn)火情,從而最大限度保護古建筑.
在完成火災探測器的布置方案后,根據(jù)《古建筑木結(jié)構(gòu)維護與加固技術(shù)標準》(GB/T 50165―2020)[17]中的要求,需對監(jiān)測系統(tǒng)設置報警閾值.報警閾值的設置是火災探測器是否精準、及時的體現(xiàn),同時也是智能監(jiān)測平臺智能化、精確化的體現(xiàn).
傳統(tǒng)感煙探測器的報警機制均為開關(guān)量式的[18],即“0”或“1”的區(qū)別.設置一固定閾值A(chǔ),當探測到的數(shù)據(jù)超過閾值時,探測器進行報警.其報警機制見式(1):
這種傳統(tǒng)固定閾值的算法原理固然簡單,實現(xiàn)起來也較容易,但其簡單粗暴的火災判斷方法,在實際應用時,卻因探測器的漂移現(xiàn)象[19-20]而經(jīng)常發(fā)生誤報.
如圖5 所示,感煙探測器在正常工作時,其探測數(shù)據(jù)并不是一個固定值,而是在一個穩(wěn)定值附近上下波動,由于探測器的應用環(huán)境中通常懸浮著大量無處不在的塵埃顆粒,它們會隨著氣流落入煙霧探測器的迷宮中,塵埃的積累會影響探測器的靈敏度,使其發(fā)生誤報警,且隨著時間的推移,光電發(fā)射器和接收管的老化也會導致探測器對火災的響應變慢,這即是探測器的漂移現(xiàn)象.
圖5 漂移現(xiàn)象導致的誤報Fig.5 Mispositives caused by the drift phenomenon
為了解決固定閾值算法易產(chǎn)生漂移的問題,本文采用了Mann-kendall 算法對探測器進行閾值設定,以減少誤報,提升監(jiān)測系統(tǒng)的準確性.Mann-Kendall 算法屬于趨勢算法,應用于研究數(shù)據(jù)序列趨勢或突變中,一般分為趨勢檢驗及突變檢驗,是一種非參數(shù)檢驗方法[21-22].在水文、氣象研究中有著廣泛的應用,通過對徑流、降水、氣溫等要素的時間序列進行趨勢、突變分析,從而判斷各要素未來的情況.
定義X(n)為感煙探測器在時間段n內(nèi)的輸出信號序列,其代表了在時間段n內(nèi)的煙霧濃度變化情況.則有符號函數(shù)見式(2).
式中:Sign 為符號函數(shù);j為時間序列的第j個值;i=j+1,且0 即對于n時間段內(nèi)的某一時刻Xi,若煙霧濃度信號大于其前一時刻的濃度信號Xj,則輸出為+1,因此,無論煙霧濃度的信號值是大是小,只要前一時刻大于后一時刻,均記為+1,相反則記為-1,相同則記為0.此種計數(shù)方式的優(yōu)點則在于忽略了具體數(shù)值的大小,只強調(diào)前后值是增大還是減小,避免了某一瞬時時刻的漂移值大于固定閾值,從而引起誤報. 此時,便引出Mann-kendall趨勢檢驗的統(tǒng)計量S見式(3). 式中:當n≥8時,S服從正態(tài)分布,其均值為0. 對統(tǒng)計量S求方差為: 式中:b為分組數(shù);ta是第a組數(shù)據(jù)的個數(shù). 對統(tǒng)計量S進行標準化,得到式(5). 此時,Zc服從標準正態(tài)分布.Zc為正值時則表示當前數(shù)列趨勢為遞增,即火災探測器在某一時間段n內(nèi)測得的煙霧濃度是遞增的.因此,設置合理的n值以及Zc的置信區(qū)間,即可在無規(guī)律的監(jiān)測信號中掌握煙霧濃度的變化趨勢,同時也避免了漂移產(chǎn)生的誤報信號. 火災探測器為實時動態(tài)的監(jiān)測,一般火災探測器每3 s生成一個數(shù)據(jù),根據(jù)《點型感煙火災探測器》(GB 4715—2005)[23]要求,點型感煙火災探測器應在30 s 內(nèi)做出報警,即要求對30 s 內(nèi)產(chǎn)生的10 個數(shù)據(jù)進行判斷處理.一般而言,對每30 s 產(chǎn)生的數(shù)據(jù)進行一次處理,即每隔30 s 處理一次數(shù)據(jù),這樣會使得報警的效率降低,對火災曲線的判斷力也會降低. 對于以上情況,本文將監(jiān)測系統(tǒng)中的Mann-Kendall 算法進行迭代優(yōu)化,如圖6 所示,以10 個數(shù)據(jù)為一組,將新產(chǎn)生的數(shù)據(jù)認定為新一組的“第10個數(shù)據(jù)”,將前一組的第10 個數(shù)據(jù)認定為新一組的“第9個數(shù)據(jù)”,以此類推至前一組數(shù)據(jù)的第2個數(shù)據(jù)認其為新一組的“第1 個數(shù)據(jù)”,即將新數(shù)據(jù)與前一組的9 個數(shù)據(jù)組合為新的一組數(shù)據(jù)進行處理,這樣就實現(xiàn)了數(shù)據(jù)處理的連續(xù)性,提高了數(shù)據(jù)處理效率.設定置信區(qū)間為大于85%,則認為這10 個數(shù)據(jù)的增加趨勢可信,即這30 s 內(nèi)煙霧濃度上升.在標準正態(tài)分布表中,85%的置信區(qū)間對應的Zc值為1.04,即Zc值大于1.04,則探測器進行報警.此部分在監(jiān)測系統(tǒng)中,為監(jiān)測平臺在調(diào)取數(shù)據(jù)庫數(shù)據(jù)后的數(shù)據(jù)分析中應用,以代碼的形式體現(xiàn),部分代碼見圖7. 圖6 迭代優(yōu)化示意圖Fig.6 Schematic representation of the iterative optimization 圖7 Mann-Kendall算法迭代優(yōu)化后部分代碼Fig.7 Partial code of the Mann-Kendall method after iterative optimization 智能火災監(jiān)測系統(tǒng)包括探測器系統(tǒng)、監(jiān)測數(shù)據(jù)分析與處理、狀態(tài)評估、實時預警等模塊,在古建筑群內(nèi)數(shù)量龐大的探測器系統(tǒng)會實時產(chǎn)生海量的監(jiān)測數(shù)據(jù),通過對數(shù)據(jù)的集成化管理,提高了處理火災隱患的準確性,方便了對火災安全的管理. 對于錯綜復雜的古建筑群而言,應用BIM 技術(shù)可以對建筑群進行信息化和可視化管理,也可將探測器與古建筑群進行實時聯(lián)動.本文利用已有的BIM 平臺——xBIM(eXtensible Building Information Modelling)平臺[24-26],進行二次開發(fā),設計古建筑火災實時監(jiān)測平臺.xBIM 是一個.NET 工具包,其可以構(gòu)建從命令行應用程序到Windows 應用程序、Web服務擴展的所有內(nèi)容.在平臺中,以IFC 格式讀取BIM 模型,全面支持幾何、拓撲操作和可視化.本文以Visual Studio 為開發(fā)工具、C#為語言、.NET 為開發(fā)框架,搭建平臺界面. 對于探測器產(chǎn)生的實時數(shù)據(jù),應用SQL Server建立數(shù)據(jù)庫[27-28].SQL Server 是Microsoft 開發(fā)設計的一個關(guān)系數(shù)據(jù)庫智能管理系統(tǒng),以C#和 T-SQL 進行混合編程,具備使用方便、可伸縮性好、軟件集成度高等優(yōu)勢,方便火災探測器海量數(shù)據(jù)的儲存及調(diào)用.本文以SqlDataReader(Sqlcon)的方式讀取數(shù)據(jù)庫,以SqlCommand(SQLstr)執(zhí)行添加、修改和刪除操作. 采用SQL Server 創(chuàng)建結(jié)構(gòu)化數(shù)據(jù)庫后,將監(jiān)測數(shù)據(jù)儲存在網(wǎng)絡云中,在xBIM 平臺中對數(shù)據(jù)進行調(diào)用和閾值分析,這樣方便了數(shù)據(jù)的管理與檢索,也極大提高了監(jiān)測系統(tǒng)的運行工作效率.對于明清古建筑群火災監(jiān)測,其數(shù)據(jù)庫的基本需求為:以古建筑單體為監(jiān)測對象,包括ID 編號、名稱、位置以及建筑防火等級,每個監(jiān)測對象上的探測器數(shù)量;對于探測器,應包括探測器的編號ID、安裝位置、安裝時間、預警閾值以及備注;對于探測器監(jiān)測到的數(shù)據(jù)應根據(jù)時間進行記錄. 對以上需求進行梳理,并將其轉(zhuǎn)換成對應的數(shù)據(jù)表. 感煙探測器的相關(guān)信息儲存于火災探測器數(shù)據(jù)表中,其邏輯結(jié)構(gòu)如表2所示. 表2 火災探測器數(shù)據(jù)表Tab.2 Fire detector data 以古建筑群內(nèi)的各個建筑單體為監(jiān)測對象,需有明確的建筑位置,并注明建筑防火等級,其邏輯結(jié)構(gòu)如表3所示. 表3 監(jiān)測建筑數(shù)據(jù)表Tab.3 Monitoring building data 將監(jiān)測數(shù)據(jù)置于監(jiān)測數(shù)據(jù)表中,其邏輯結(jié)構(gòu)如表4所示. 表4 監(jiān)測數(shù)據(jù)表Tab.4 Monitoring data 以某明清古建筑群為例,在SQL Server 上使用T-SQL 語言和圖形操作界面對數(shù)據(jù)表格進行創(chuàng)建后,如圖8所示. 圖8 監(jiān)測數(shù)據(jù)庫Fig.8 Monitoring database 以某明清古建筑群為例,進行火災監(jiān)測系統(tǒng)實施.如圖9 所示,輸入提前預設的賬號和密碼,即可登錄監(jiān)測平臺主界面. 圖9 火災智能監(jiān)測平臺登錄窗口Fig.9 Login window of the intelligent fire monitoring platform 進入主界面后,如圖10 所示,可以看到監(jiān)測項目名稱、項目位置、古建筑數(shù)量以及火災探測器數(shù)量等概況,在主界面還有監(jiān)測古建筑群的BIM模型. 圖10 火災智能監(jiān)測平臺主界面Fig.10 Main interface of the intelligent fire monitoring platform 將監(jiān)測方案的設計儲存在數(shù)據(jù)庫中后,在平臺管理中,有“探測器管理”這一選項,可以對火災探測器進行管理.如圖11 所示,進入管理界面后,在右側(cè)可以看到所有已添加的探測器信息,選定相關(guān)探測器后,可以看到此探測器的基本詳細信息,并可以對其參數(shù)進行設定和修改. 圖11 火災探測器管理界面Fig.11 Fire detector management interface 對于火災探測器的實時監(jiān)測,如圖12 所示,在“實時監(jiān)測”這一頁面中,左側(cè)有古建筑群中每個建筑設置的探測器列表,點擊任意一個探測器,即可看到每個探測器的狀態(tài),包括探測器的信息、監(jiān)測實時數(shù)據(jù)以及實時動態(tài)曲線圖. 圖12 實時監(jiān)測界面Fig.12 Real-time monitoring interface 當監(jiān)測到數(shù)據(jù)觸發(fā)報警機制時,便會出現(xiàn)彈窗警示,如圖13 所示.在火災警報窗口,會注明發(fā)生報警的探測器ID 以及當前的趨勢置信區(qū)間對應的正態(tài)分布值,并記錄當前火災發(fā)生的時間. 圖13 火災報警窗口Fig.13 Fire alarm window 1)以火災危險源、建筑結(jié)構(gòu)作為火災主要影響因素,以火災動力學模擬作為手段,對古建筑進行火災探測器的布置優(yōu)化,可提高火災探測器的高效性、準確性. 2)對于古建筑群內(nèi)龐大的火災探測器系統(tǒng),集成化火災智能監(jiān)測平臺的開發(fā),極大地方便了對火災安全的管理,提高了火災報警的及時性,對古建筑群的文物保護提供了新思路. 3)實時迭代優(yōu)化后的Mann-Kendall 算法,可避免傳統(tǒng)固定閾值算法下的漂移問題,減少感煙探測器的誤報頻率.云數(shù)據(jù)庫的開發(fā),對海量大數(shù)據(jù)的儲存、調(diào)用提供了高效便利的管理工具,也為古建筑群的實時監(jiān)測提供了新的技術(shù)手段.2.3 實時監(jiān)測下的迭代優(yōu)化處理
3 古建筑群火災智能監(jiān)測平臺搭建
3.1 開發(fā)工具及環(huán)境
3.2 監(jiān)測數(shù)據(jù)庫開發(fā)
3.3 平臺監(jiān)測實施
4 結(jié)論