今日頭條
官方微信
官方抖音
案例頻道
1 引言
地鐵是一類位于地下的特殊建筑，地鐵車站是人流密集的公共場所，根據國家消防規范和地鐵設計規范的要求，必須設置火災自動報警系統和消防系統及設備。目前，地鐵內均設有專業的火災報警系統（Fire Alarm System，FAS），擔負著對建筑內火災的探測、報警及聯動控制消防設施的功能。2003年2月發生在韓國大邱地鐵的火災，造成重大人員傷亡，慘痛的教訓讓人們在進行地鐵建設時更加關注地鐵相關系統對火災的探測及消防。據統計，在火災事故中，造成人員傷亡多是由有毒煙氣造成的，因此火災前期的防煙與排煙至關重要，如何實現地鐵防排煙系統設備的聯動控制一直是業界爭論的問題。在新版《地鐵設計規范》（GB50157-2003）中就此明確說明，可以采取兩種方式：
① FAS系統直接聯動控制；
② 通過地鐵環境與設備監控系統（Building Automation System，BAS）進行聯動控制。這里暫且不討論兩種方式的利弊。
深圳地鐵正是采用第二種方式，即通過BAS系統實現對防排煙系統設備進行聯動控制的。
2 重點與難點
采用該種方式，將面臨和解決以下重點及難點問題。
2.1 BAS與FAS的接口問題
一般情況下地鐵不設置專門防排煙系統設備，多數情況下采用通風系統的共用設備作為防排煙系統設備，它們在正常工況下實現通風換氣的功能，由BAS系統實現控制?；馂那闆r下則用于防排煙，此時，對于第一種聯動方式，將由FAS系統實現對它們的控制，而采用第二種方式時，則還是由BAS系統實施控制，這里只討論第二種方式。采用第二種方式時，BAS則需要解決何時進行聯動控制問題，由于火災工況的探測是由FAS系統實現的，因此這種情況下不可避免地涉及到兩系統間的接口。提到接口，其實現一般有三種方式：I/O硬線接口、低速率異步通信接口和網絡接口。I/O硬線接口的特點是接口簡單、容易實現，但物理連接偏于復雜。而另兩種方式的特點是物理連接簡單、信息量大，但需要進行協議轉換和解釋，有一定技術難度。
根據《地鐵設計規范》的要求（參見19.2.7和20.2.3條款），兩系統間采用通信接口，BAS系統將通過通信接口獲得FAS產生的報警信息及模式聯動控制命令信息。一般而言，FAS報警主機均帶有通信接口，但不是為實現系統間接口設置的，而是多用于報警主機之間聯網或連接其外圍監控設備（如圖形終端、打印機等），且協議一般是基于ASC碼的不公開的專用協議。深圳地鐵FAS系統采用的是美國愛德華公司的EST3系統，該系統主機帶有兩個異步串口（RS-232），一個設置為圖形終端接口，用于連接FAS工作站，另一個設置為打印機接口，其協議是主機固有的打印機協議。BAS系統正是要利用這一接口實現和FAS連接，接收FAS信息從而實現聯動控制，如何在協議層能準確接收并解釋其信息是實現聯動控制的關鍵。
另外，防排煙系統設備聯動控制的重要性決定了系統設計時須充分考慮BAS與FAS接口的可靠性。由于EST3主機協議是無應答協議，存在丟數據的風險，因此只通過報警主機單路徑和BAS接口是不夠的，有必要考慮和開辟系統間的第二信息路徑。
2.2 BAS接收信息的實時性和可靠性
由上可知，EST3系統打印機協議是一種基于事件的無應答的協議，該協議是固有協議，應用中無法改變，且協議中無握手，無通信建立過程，更沒有信息重發機制，因此如何保證BAS能可靠接收信息，是系統結構設計及信息處理方法中需要考慮的問題。
2.3 BAS響應信息、實現聯動控制的實時性和可靠性
當BAS系統能正確接收FAS信息后，BAS將迅速整理、分析、分揀信息，判斷并生成控制命令，協調系統內相關控制器動作，從而實現聯動控制，這些屬于信息處理流程，同樣BAS系統需要提供可靠機制和硬件平臺來支持該流程的實現。
3 系統整體設計
根據上面的分析，為提高兩系統互連的可靠性，自然要考慮到系統間的網絡接口，利用車站局域網，作為兩系統互連的另一條信息路徑。如圖1所示，BAS和FAS有兩條鏈路實現連接。
圖1 系統整體連接圖
3.1 底層路徑
利用EST3主機的一個RS-232異步串口和BAS系統的PLC直接連接，該接口事先由EST3系統將其配置為打印接口。深圳地鐵項目中，BAS系統控制器采用的是美國羅克韋爾（Rockwell）公司的Control Logix系列可編程控制器（Programmable Logic Controller，PLC），接口模板采用的是美國Prosoft公司的MVI56-ADM模塊，該模板能很好地和Control Logix系列PLC集成，并能夠直接安裝其框架內，它提供了3個應用物理接口，并可直接通過背板總線實現和PLC的CPU模板進行數據交換。該模板提供了一個嵌入式系統環境（16位DOS環境），并且為用戶提供了豐富的應用程序接口（Application Program Interface，API），用戶可以利用這些API編寫適應各種接口應用的程序運行于該模板中。深圳地鐵的BAS利用該模板提供的資源，編寫了EST3主機打印機協議的接口驅動程序，該驅動用于EST3協議應用層的解釋工作，并將相關數據映射到PLC的共享內存中用于PLC程序處理。
3.2 上層路徑
EST3主機提供另一個RS-232異步串口用于和FAS監控工作站連接，FAS監控工作站同時和BAS監控工作站接入車站局域網，BAS監控工作站通過局域網從FAS監控工作站獲取數據，并傳送至BAS的PLC控制器中，從而實現兩系統通信數據路徑的冗余。通過這樣的系統設計，從邏輯結構上保證了BAS和FAS之間的通信可靠性，使得BAS的PLC控制器能分別通過兩條路徑獲取數據，從而提高接收FAS數據的可靠性。
4 接口協議
接口協議的轉換及解釋是采用這種方式實現聯動控制的關鍵。
系統在結構上實現了通信路徑的冗余，接下來將面對如何可靠接收并解釋FAS的專用協議，并傳送至BAS的可編程控制器中。在這兩條通信路徑中，涉及了3種協議，FAS專業提供了2種通信協議：
① 用于底層的無應答的EST3協議；
② 用于上層的有應答的基于TCP/IP（Transfer Control Protocol/Internet Protocol，傳輸控制協議/網際協議）的CBP協議（CGP and BAS Protocol，CBP；CGP：Color Graphic Package，彩色圖形軟件包，是EST3系統的軟件包）。另外是利用Rockwell公司的RSLinx通信引擎，基于TCP/IP的控制與信息協議（Control and Information Protocol，CIP），關于CIP這里不作詳細介紹，只針對EST3系統的兩種協議做論述。
4.1 EST3協議
如前所述，EST3提供的是一種基于事件的無應答的打印機協議，這就要求作為接收方的驅動必須做到接收迅速、解析準確、傳送及時。首先，驅動的接收方式為中斷接收，由于是通過硬件來觸發的，與常規的輪詢方式比，其最大的優勢是延遲時間極短，延遲在納秒（10-9秒）級；其次，解析采用了“滑動窗口”機制，對數據的解析是基于單個字節的，這樣可以確保在解析時不會誤丟數據；最后，在解析出一幀完整的信息后，立即把數據放入PLC共享內存，通知PLC有新的事件，同時，與PLC的數據交換引入握手機制，可以確保數據被PLC接收。
4.2 CBP協議
FAS監控工作站提供的是基于TCP/IP有應答的協議，這條數據路徑作為冗余通道。提供三種應答協議，如圖2所示。其一是網絡測試幀，用于雙方的相互診斷，協議文本內容固定，監控站定期發送，驅動收到后只需復制文本，回饋給監控站作為響應；其二是變更信息協議，用于驅動查詢監控站是否存在新的故障信息，驅動定期發送查詢幀，如果收到響應并發現有新的故障，驅動以事件的方式通知本地應用層；其三是總召喚信息協議，用于驅動查詢監控站當前存在的所有故障信息，驅動定期發送總召喚查詢幀，如果收到響應并發現有新的故障，驅動以事件的方式通知本地應用層。
顯然，兩種協議都有各自特點，EST3協議最大的特點是快速，但協議有先天缺陷，存在丟失數據的可能；TCP協議最大的特點是可靠，其缺點是存在較大延遲。當同時采用兩種協議接收數據時，可以達到相互取長補短的效果，兩系統之間的數據傳遞迅速、可靠，使BAS能夠滿足聯動控制系統響應性指標要求。
圖2 三種應答協議
5 聯動控制過程
實現聯動控制有3個過程：
① 接收有效的報警信息；
② 模式優先級及沖突判斷；
③ 發布模式命令，實現火災模式控制。具體流程如圖3所示。
圖3 聯動控制過程流程圖
5.1 接收有效的報警信息
在由驅動層有效可靠的接收數據并傳送至BAS系統后，BAS系統控制器的應用程序須要對這些數據進行及時的、可靠的讀取和處理，以避免數據被新的事件數據所覆蓋，造成事件丟失，為此PLC應用程序中采取以FAS事件最小更新周期的1/3時間為周期做定時查詢，以可靠獲取接口驅動層傳遞來的數據，具體是這樣實現的：
在PLC應用中，專門建立一個周期性的（定時中斷）接口數據處理任務（FAS_Handler），用于讀取并處理PLC共享內存數據。由前面分析可知，由于底層鏈路的數據傳遞較快，則PLC周期任務的時間以底層鏈路數據更新周期為基準。底層物理接口為異步串口，波特率9 600bps，接收1幀數據所需時間大于60ms，故將該接口處理任務的周期設定為20ms（即20ms的定時中斷），這樣確保BAS能及時可靠地讀取FAS信息。
接口數據處理任務的功能是讀取并處理接口數據。具體流程如圖4所示。根據設計，BAS系統只響應FAS的模式控制命令，而FAS系統不能直接傳遞模式命令，BAS必須要對FAS數據進行整理和過濾，分揀出代表模式命令的信息（FAS輸出的信息是其所有的事件，如火警、手報、溫感、矩陣、與組、故障、狀態等，而BAS關心的只是有效的邏輯與組編號，FAS事先針對不同防火/煙分區的煙感或溫感探頭，設置不同的邏輯與組，當該組內相鄰2個探頭報警時，FAS將輸出該與組的編號，作為該防火/煙分區確認的火災報警信息，與組編號代表特定防火/煙分區的模式命令，因此BAS將在FAS傳遞的眾多信息中分揀與組號信息，查表確定對應的防排煙模式命令編號）。另外，BAS系統通過CBP協議接收上層通信路徑傳遞來的與組編號信息，這一層的數據過濾在運行于BAS監控工作站的接口驅動進程中實現。BAS監控工作站利用CIP協議將該信息實時寫入PLC的另一共享內存中，同樣PLC將根據該信息查表產生對應的防排煙模式命令編號。由于火災事件是有先后順序的，因此在接口數據處理任務中設計了一個長度為20的數組文件作為事件隊列（First In First Out，FIFO）FAS_Evt_FIFO，用于緩存防排煙模式號，為BAS后續處理做準備。此時事件隊列程序模塊將比較兩條路徑傳遞來的信息，如果數據相同，則視為同一火災事件，如果不同，則作為兩個不同的事件，這些事件以模式號的方式進入事件隊列。
至此，聯動控制的第一個步驟完成，這一步是BAS實現聯動控制的基礎。
圖4 數據處理流程圖
5.2 模式優先級及沖突判斷
地鐵一般設有3類風系統：隧道風系統，車站公共區風系統（大系統）和設備及管理用房風系統（小系統）。根據工藝設計，這些風系統設備在不同的運營工況時動作是不一樣的，不同工況下多設備不同的運行狀態組合即所謂的模式，BAS將根據情況對這些設備進行群組控制即模式控制，以適應不同的工況。地鐵工況一般有火災工況、阻塞工況、正常工況等，對應有防排煙模式、阻塞模式和正常模式等，其中防排煙模式具備最高的執行優先級。另外，當同一風系統對應的不同防火（防煙）分區同時出現火災時，根據要求要啟動不同的防排煙模式，如果不同的模式對同一設備的動作要求不一樣的情況，這種情況定義為模式沖突，此時BAS系統在響應并執行第一個模式的時候就不能執行第二個模式，以上工作全部由BAS可編程控制器來進行判斷和處理。當出現火災時，BAS系統首先根據事件隊列里的模式號來判斷工況，以決定能否優先執行該模式（火災工況是具有最高優先級），接著BAS要根據模式號進行模式沖突判斷，看是否和當前同級別的模式沖突。以上判斷的結果就意味著聯動控制的第二步完成。
5.3 發布模式命令，實現火災模式控制
經過上述2個步驟，事件隊列里的某個模式經判斷能夠執行時，BAS系統將根據該模式號查表，取出對應的設備命令分解傳輸到各個就地級控制器中，由就地級控制器實現對防排煙設備的控制，至此完成聯動控制。
6 聯動控制的響應性及實時性
根據《消防聯動控制設備通用技術條件》（GB16806－19987）中對聯動控制的有關控制方式、響應性、反饋顯示等技術指標提出了具體要求。其中要求聯動控制系統在接收FAS報警信息后需在3秒內發出聯動控制命令（參見4.2.4條款），這里分析一下BAS系統聯動控制的響應性和實時性。
在做系統設計時，對BAS聯動控制的響應性和實時性采取了下列措施：
(1) 接口驅動采用中斷方式接收FAS的報警信息，并實時更新到PLC的共享內存中；
(2) BAS系統采用工業級控制器，其運算速度<0.1ms/k基本指令，應用程序掃描周期一般為毫秒級；
(3) BAS控制器之間的網絡采用確定性、高速控制網絡，使得聯動命令的傳遞同樣在毫秒級內完成。
圖5 聯動過程所需的時間
下面根據深圳地鐵的實際應用，定量計算一下整個聯動過程所需的時間T，如圖5所示。T應是從FAS系統產生確認的火災報警開始，到防排煙設備開始動作所經歷的時間，即：
T＝T2＋T3＋T4＋T5＋T6＋T7（T2嚴格意義上是FAS系統的延遲，根據規范描述，聯動控制系統的時間延遲計算不應包括這段時間）。其中：
T2：邏輯與組數據幀傳送時間約為60ms（≥57byte/frame，10bit/byte，9 600bps，T2＝（57×10）/9600＝59.375ms）；
T3：接口驅動執行時間，由于采用中斷方式，其執行時間幾乎和T2同步，可視為無延遲；
T4：PLC共享內存數據更新時間，由于接口模板是采用背板總線方式和PLC的處理器進行數據交換，PLC背板通信帶寬為幾百兆，其時間延遲為微妙級，同樣視為無延遲；
T5：BAS系統PLC控制器接口處理任務的周期，20ms；
T6：BAS系統PLC應用程序掃描時間，小于150ms；
T7：包括3個時間段：模式命令的傳遞時間（BAS主控PLC和就地PLC之間的數據通信時間：80ms）、就地PLC控制器應用程序掃描時間（<80ms）和I/O模塊數據更新時間（20ms），T7＝80＋20＋80＝180ms；
則：T＝60＋20＋150＋180＝410ms
由上可知T<0.5s，遠遠優于規范中所規定的響應性指標要求（3s）。需要指出的是，在現場多次的放煙試驗時，從點煙到FAS產生與組信息歷時（T1）平均在20～30s之間，這主要和煙氣的擴散速度及煙感探頭的布置位置、密度和敏感性有關。另外從BAS輸出設備級命令到該防排煙模式設備均達到模式要求的狀態最長歷時（T8）近1.5分鐘，這主要和有些多葉風閥動作到位的行程時間過長有關，一般風機的啟動時間為幾秒鐘，電動防火閥則一般在1秒內完成動作。由上可知，聯動的整個過程中，BAS系統的時間延遲相對設備動作和模式執行所用的時間是很小的，使得BAS在接收到確認的報警信息后能在第一時間內響應并控制防排煙設備動作，以確保防排煙效果。
7 結語
深圳地鐵已于2004年12月28日勝利通車，深圳地鐵于國內首次實現了以BAS系統（規范名稱，項目名稱叫EMCS系統）為主的3個專業集成（EMCS＋FAS＋PSACDA），集成的重點問題是接口、共享平臺和應用流程，深圳地鐵正是在接口技術上采取了多種有效、可靠的方式使得3個專業能很好地結合在一起，既能發揮各個專業自身的特點，同時在特殊情況下又能共享數據，很好的實現系統間的聯動控制，從而為用戶提高運營的自動化水平及工作效率提供技術保障。BAS和FAS系統之間的聯動只是該系統中較為典型的集成應用，這種應用在通車前消防驗收的整個過程中所表現出的優異效果使得該聯動控制方式得到人們和業界的認可。
北京市公安局海淀分局備案號：11010802023656號