陳瑞峰
上海電氣集團股份有限公司 中央研究院 上海 200070
?
基于組態軟件的城市軌道交通綜合監控系統與火災報警子系統通信協議研究*
陳瑞峰
上海電氣集團股份有限公司 中央研究院 上海 200070
在城市軌道交通綜合監控系統(ISCS)中,火災報警系統(FAS)是重要的子系統之一。在現場工程實踐中,由于各個廠家設備的特殊性,不具備通用的通信協議與驅動,導致組態監控軟件無法與設備進行直接通信,因此需要進行定制化開發。提出了一種基于組態軟件的ISCS與火災報警子系統的通信協議,對通信流程進行了介紹,并對報文幀結構進行了分析研究。這一通信協議實現了監控系統與報警子系統之間的數據互通,可實時反饋報警信息,效果良好。
組態軟件; 城市軌道交通綜合監控系統; 火災報警系統; 通信
軌道交通車輛等裝備的國產化和產業化已被列為上海市工業發展的重點[1]。在不斷對車輛等硬件設備進行研發的同時,更應加強對整體系統監控軟實力的提升。其中,城市軌道交通綜合監控系統(ISCS)是重要組成部分,通過專用接口,集成或互聯了軌道交通中的眾多專業自動化子系統,如電力監控系統(PSCADA)、環境與設備監控系統(BAS)、火災報警系統(FAS)等。利用統一的信息平臺對各專業子系統進行全面監控,實現各系統之間信息的無障礙交互和各子系統之間的有效聯動[2-3],從而保證軌道交通能安全高效運行,為城市軌道交通現代化管理提供信息化基礎。
由于許多子系統有特殊性,因此需要對通信驅動進行定制化開發。實踐中,以能美FAS為基礎,通過各種傳感器將火災信號傳輸至火災監控中心主機,監控中心主機按設計程序聯動自動噴淋、緊急廣播、火災電話等子系統,并與閉路電視系統、給排水系統等實現聯鎖控制,從而將火災的損失降到最小[4]。
筆者對通信驅動的實現方法及ISCS通信過程進行了研究,解決了ISCS與子系統不兼容的問題,彌補了現有平臺軟件的不足。
ISCS多采用三級控制的分層分布結構,由中心級綜合監控系統、車站級(車輛段)綜合監控系統及網絡系統構成。網絡系統由主干網與局域網組成,每個車站的監控信息先由車站級局域網傳輸至主干網,再通過主干網傳輸至控制中心,進而實現多層次多系統的綜合監控。作為綜合監控系統核心的軟件系統,按照功能邏輯可分為三層: 數據接口層、數據處理層及人機接口層[5],如圖1所示。

圖1 ISCS軟件系統架構示意圖
組態軟件可針對ISCS進行專業化開發,為用戶提供針對數據采集及過程控制的專業開發環境和系統運行環境。上海電氣集團股份有限公司的NetControl是一款針對多行業監控系統應用的組態開發工具,可在軌道交通中實現ISCS所需要的相應界面及圖形工具。
ISCS接收FAS監控對象的主要運行狀態,包括火災報警或重要系統報警,并顯示具體報警部位。當發生火災時,車站級FAS直接向BAS發送模式指令,并上傳至ISCS,監視FAS發出的火災模式及BAS執行的結果狀態,根據火災模式,啟動廣播系統進入消防廣播狀態,然后進行火災報警及故障數據的存儲。系統還具有報警信息、狀態信息的報表分類查詢及打印功能。
火災信息探測與數據處理方式、火災探測器與火災報警控制器之間的配合,決定著FAS的功能與結構形式,能美R-23系列FAS采用分布智能系統,結構如圖2所示[6]。分布智能系統中的火災探測器,僅為火災傳感器,無論煙霧影響有多大,探測器本身并不報警,而是將煙霧影響產生的電流電壓變化信號通過編碼電路傳送至區域消防主機,再由主機內置軟件進行探測器信號與大量典型信號的比較,產生一系列報警信號和控制動作。這樣的處理方式能夠大大降低誤報率,提高可靠性[7]。

圖2 能美FAS結構示意圖
通過定時掃描發送數據表,通信軟件能夠將由圖形監控軟件下發的數據迅速發送至指定的FAS。通過實時掃描各FAS設備的通信端口,通信軟件可以快速取得各個FAS上傳的數據,通過格式轉換后立即上傳至數據庫,供圖形監控管理軟件讀取處理。整個系統是綜合集成不同FAS的監控平臺,實現了不同種類FAS信息的共享,降低對計算機硬件設備的需求,多個不同種類FAS只需使用一臺監控計算機。
組態軟件中通信驅動的開發與開發環境和運行環境高度相關,通信驅動需要讀取用戶配置,并根據用戶配置與具體協議形成報文格式和解析方式。在組態軟件中,用戶進行輸入輸出接口配置時需要選擇與現場實際要求相符的通信方式。串口通信需要設置端口號、波特率、校驗位和數據位等信息,要針對實際情況進行具體設置。在通信驅動開發中,可以通過開發環境的開放接口進行可擴展應用程序標記語言(XAML)的設計,效果如圖3所示。

圖3 用戶設備信息配置界面
火災報警子系統具備的功能包括當前和歷史的報警、故障信息查詢,監測點現場環境狀態數據查詢,消防設備、防火分區查詢,設備布點信息瀏覽等。能美設備的接口軟件對外通信端口配置(GTW)服務模塊用于顯示GTW的類型、通信參數、開啟狀態、故障狀態和數據通信等。火災報警子系統通信流程如圖4所示。

圖4 火災報警子系統通信流程
通信連接過程的實現方法如下: 首先重寫底層的連接方法[8-11],然后再做一個通信標志位,用于驗證通信連接進入第幾步,同時指定回復信息的格式要求,最后在對應的服務方法中進行具體格式要求的解析,完成連接確認。具體編碼如下:
protected override ExecutionResult Connect()
{
ExecutionResult newConnect=new ExecutionResult();
if(connectMask==false)
{
CommandInfo InitcmdInfo1=new CommandInfo() {Content=mProtocol.InitPackage()};
ResponseInfo responseInfo1=new ResponseInfo()
{
ResponseType=ResponseType.L,Length=5,
};
InitConnect.Add(InitcmdInfo1, responseInfo1);
var conresult_Init=base.GetServiceResult(InitConnect, “InitPackage”);
if(conresult_Init!=null)
{
if((bool)(conresult_Init))
{
newConnect.IsSucceed=true;
Send(mProtocol.ACKbag());
}
else
{
newConnect.IsSucceed=false;
Send(mProtocol.NAKbag());
}
}
else
{
newConnect.IsSucceed=false;
newConnect.Message=Resources.ErrCheck;
}
}
圖4中ACK(肯定應答)包與NAK(否定應答)包的具體格式見表1。

表1 應谷數據包幀格式
能美FAS的通信幀格式分為讀數據和寫數據,數據包信息編碼統一為D,稱為DATA包,控制包信息編碼統一為C,稱為CTL包,報文幀標準格式見表2。

表2 報文幀標準格式
表2中的設備編碼包括接口模塊號和設備所屬系統信息,在圖3所示設備參數中有具體體現。此外,報文幀中還包括模擬或數字檢測量的長度、相關數值,以及具體時間和備注信息。
在通信過程中,設備先向ISCS發送PING包,用于定時確認信息,PING包的幀格式見表3。當串口成功打開后,系統發送INIT(初始化)包,其幀格式見表4。基于外部應用系統要求,GTW模塊可以發送當前現場狀態信息,支持兩種發送級別,其中I級發送所有實時報警、故障、動作和狀態信息,F級僅發送實時報警信息,缺省設置為F級。

表3 PING包幀格式

表4 INIT包幀格式
組態軟件實現發送幀的方式有兩種: 一種是直接建立Byte數組,逐個字節添加;另一種是直接建立String類型的字符串,然后再單獨另寫方法將其轉換為Byte數組。
當監控中心與FAS的通信成功連接后,FAS設備將發送數據信息幀D002 02 1013 0 004 02 05 20050421 103607 T9N,其具體含義見表5。

表5 數據幀具體含義
通過人機接口可以在屏幕上直接進行控制操作,改變運行狀態,系統將傳回的信息直觀地在屏幕上顯示出來。接收到報文后,工作人員可方便讀取狀態信息及所對應的時間信息。FAS規定了探測器和終端設備之間不同狀態編碼的具體含義,其中004對應的功能碼為報警類型,報文含義為2號主機,地址1-013,報警號05,發生時間2005-04-21 10: 36: 07。
發生報警時,FAS直接向BAS發送模式指令,并上傳ISCS,通知系統廣播播放信息。不同狀態編碼對應不同的信息含義,在具體實踐中,可將狀態編碼作為整個系統監測點的點表來使用。
表5中N表示正常信息,對CTL包備注編碼,固定為字符N。T9為校驗和的數值。若報文解析正確,ISCS會發送ACK包,表示信息接收成功。相反,如數據包解析不正確,則認為通信失敗,回復NAK包。若6次連續接收到NAK包或超過500ms 未接收到任何包,則系統認為通信結束。
組態軟件需對發送的報文進行具體解析,其中重要的一個環節就是判斷狀態編碼。首先遍歷整個寄存器列表,然后判斷狀態編碼是否一致,如果一致,那么將對應的值寫入相應的寄存器中,其效果如圖5所示。

圖5 火災報警子系統讀取報警信息
基于上述原理及實現方式,可利用FAS的對外串行數據通信接口,實現監控終端系統對子系統數據的互通互聯。通過分析FAS的數據通信協議,可在上傳至ISCS的數據中獲得報警部位、報警類型、系統運行狀態、故障信息、工作記錄等關鍵信息,便于監控室相關工作人員使用。
ISCS與車站FAS的通信至今仍未形成統一的標準,且沒有成熟的解決方案,眾多廠家的設備不能實現互通互聯。為解決設備與ISCS之間的通信,通過對用戶配置信息進行讀取和建立幀格式,并與軟件接口配合,妥善解決了工程實施中的個性化通信驅動問題。筆者基于能美設備實現了FAS與ISCS間的通信,介紹了整個通信流程,有效解決了平臺與子系統間不兼容的問題。當然,筆者所述實現方式也有一定適用范圍,且存在繼續改善的空間,這些需要在后期工程中不斷驗證與完善。
[1] 尹力明,劉俊艷,馮國強.交流變頻控制系統在城市軌道交通車輛中的應用[J].裝備機械,2010(2): 44-50.
[2] 季偉斌.國內地鐵綜合監控系統應用[D].上海: 復旦大學,2006.
[3] 柳彥青,朱志平.城市軌道交通綜合監控系統淺述[J].上海電器技術.2006(4): 49-52,56.
[4] 劉鈞,馬旭東,施健.基于能美火災自動報警通信協議的串行通信的實現[J].工業控制計算機,2001,14(6): 17-20.
[5] 陽若寧.城市軌道交通綜合監控系統的組成與應用[J].湖南廣播電視大學學報,2011,47(3): 53-56.
[6] 火災自動報警系統施工及驗收規范: GB 50166—2007[S].
[7] 陳在坤.火災報警系統的后臺通信設計與實現[D].貴陽: 貴州大學,2009.
[8] NAGEL C, GLYNN J, SKINNER M. C#高級編程——C#5.0&.NET 4.5.1[M].李銘,譯.9版.北京: 清華大學出版社,2014.
[9] 王云鵬.C#新手開發實戰演練[M].北京: 中國鐵道
出版社,2009.
[10] 夏元良.火災計算機監控管理系統的設計與實現[D].大連: 大連理工大學,2006.
[11] 劉長安.火災報警通信系統設計與實現[D].沈陽: 東北大學,2007.
(編輯: 啟 德)
In ISCS, the FAS is one of the important subsystems. In the field engineering practice, due to the specificity of equipment coming from various manufacturers, it is not available to have a common communication protocol and drive, as a result, the configuration monitoring software can not communicate directly with the equipment and it needs to be built to order. presented a communication protocol between ISCS and FAS based on configuration software with an introduction on the communication process and analytical study of the frame structure of the message. This communication protocol realizes the data intercommunication between ISCS and FAS while feeding back the alarm information in real time and its function is good.
Configuration Software; ISCS; FAS; Communication
2016年12月
陳瑞峰(1988— ),男,碩士,助理工程師,主要從事通信協議研究及通信驅動開發工作, E-mail: chenrf2@shanghai-electric.com
TM-9;TP393.04
A
1674-540X(2017)02-005-05
*上海市科學技術委員會企業合作專項(編號: 15dz1180400)