軌道交通車輛車門遠程監控系統的設計與實現

張 健 陳 瑞 王少東

（南京工程學院通信工程學院，211167，南京∥第一作者，副教授）

隨著交通系統信息化建設的不斷完善和發展，交通管理正在逐步向智能化的方向發展。而遠程監測系統作為智能化交通管理最重要的信息平臺，在交通信息化系統中起著舉足輕重的作用［1］。車門是整個列車系統中安全性要求很高的部分，而列車客室車門故障率又較高，使得客室車門的可靠性成為制約列車安全、正點運營的瓶頸之一。地鐵車輛車門故障經常引起列車下線、抽線、清客等運營障礙，甚至因車門關閉問題引起旅客傷亡事故。因此，隨著列車設備老化以及故障頻發度的變化，必然引起軌道交通中央級監控部門對車門的重視，并進一步嘗試遠程車門監控技術方案。

車門遠程監測系統的基本用途，是對軌道交通中車門系統的狀態及故障信息進行收集、存儲、傳輸和利用，并以此為基礎，對車門系統的工作和故障狀態實施遠程實時監測［2－3］。相關技術人員可以根據監測系統上傳的信息分析故障原因，指揮現場工作人員解決問題，保證列車的可靠運行［4］。

1 車門遠程監測系統

車門遠程監測系統如圖1所示。系統主要由3部分構成。①前端裝置：位于軌道交通列車上每節車廂中的車載前端裝置，完成對門系統的狀態及故障信息進行實時收集、解析、存儲和上傳等功能；②傳輸信道：選用無線信道，完成數據的無線傳輸［5］；③ 監測中心：位于遠端的監測中心，完成接收數據、存儲數據，以及后臺的顯示和統計等功能。前端裝置和后臺的監測中心一起，實現車門系統的遠程實時狀態監測、故障數據存儲和統計。

值得一提的是，前端裝置完成數據的收集功能時，對車輛網絡而言應當是隱形的。即，車輛網絡感覺不到前端裝置的存在。無線傳輸信道的選擇應滿足其帶寬與數據量相匹配，且在數據傳輸過程中采取必要的保護措施，保證接收數據的無差錯和不丟失。監測中心的后臺軟件需要區分用戶，為不同類型的用戶分配不同的權限，從而保證系統的安全性；且后臺數據庫具有1＋1備份，保障數據的安全。

圖1 車門遠程監測系統圖

1.1 前端裝置

車門遠程監測系統的前端裝置是整個監測系統的核心部分，負責完成如下功能：① 監聽門控制器與車輛總線之間的交互信號；② 對上述信號進行分類處理；③ 打包準備傳輸。

1.1.1 前端裝置的硬件設計

以南京地鐵2號線為例：車廂內部通信總線為RS 485總線，且在車廂兩側各有一條RS 485總線用于連接各門控制器。為避免對車輛系統中原有系統及其功能產生影響，每個前端裝置只需完成一路RS 485總線的監聽。

前端裝置的硬件結構按照功能可以劃分為信號轉換接口、核心處理單元、無線數據傳輸模塊和裝置電源等4個模塊，如圖2所示。

圖2 前端裝置的硬件結構

信號轉換接口主要完成RS 485到RS 232（核心處理單元的串行數據接口）的信號轉換，實現基于通信協議的故障、狀態和參數采集。核心處理單元主要完成通信協議的讀取和分析、上傳數據的打包、本地數據的存取、裝置狀態的正確管理和切換等功能。無線傳輸模塊完成打包數據的無線傳輸至Internet，實現Internet與遠程監測中心之間的雙向通信。電源模塊完成車輛電源（DC110 V）到相應硬件模塊電源之間的轉換，同時提供基于鋰電池的不間斷電源，實現裝置正常斷電操作的信息無損（沒有信息被丟掉，包括斷電事件）。

1.1.2 前端裝置的軟件設計

前端裝置的軟件系統主要完成以下功能：①RS 485總線數據的組幀和解析；② 協議數據的處理策略確定和再封裝；③ 實現數據的低延遲高可靠性上傳；④ 根據列車電源的供給情況，進行合理的前端裝置工作狀態切換。

項目組在Linux系統下，采用C語言實現了上述功能。具體實現上，前端裝置的軟件系統主要由信息采集與處理模塊以及上行通信模塊2部分組成。信息采集與處理模塊完成針對門系統采集到的信息的采集與處理。首先對RS 485總線傳輸協議進行解析，獲取有用的門控信息，然后再將數據進行分類處理。數據的分類處理是指協議數據的處理策略確定和再封裝。處理過程、處理策略包含實時上傳、周期上傳和本地存儲3類。上行通信模塊完成數據的低延遲高可靠性無線上傳，其中包括實時上傳、周期上傳和應需上傳的實現。具體的軟件實現流程如圖3所示。

圖3 前端裝置軟件的流程圖

1.2 信道的選擇

為滿足系統設計的要求，數據從前端裝置上傳至監測中心的傳輸信道需達到以下要求。① 帶寬：需提供100 kbit／車廂；②時延：從數據的產生開始，到最終監控終端讀取數據的端到端延時小于1 s；③丟包率RPL：為了保證系統最終的RPL＝0，對無線信道RPL要求＜2%。

系統設計時采用CDMA3G通信模塊與監測中心網關的雙向通信。CDMA通信模塊以固定時間間隔向監測中心網關發送數據，實現了數據的低延遲、無差錯上傳。為保證數據不丟失，采用了確認－重傳的方法。即：監測中心網關每收到一個數據包，需給門監測器一個確認信號；如間隔一定時間沒有收到，門監測器將重傳該數據包。

1.3 監測中心

監測中心包含監測網關、數據服務器、監控終端和防火墻（見圖4）。監測數據服務器用于存儲所有被監測的門系統數據。監測網關負責與各前端裝置的雙向通信。監控終端用于實現相關信息的顯示。

圖4 監測中心系統組成

2 試驗測試結果

為了驗證系統的實用性，本系統在南京康尼機電股份公司的內部試驗臺架和南京地鐵2號線的一輛列車上進行了裝車測試。測試主要包括總線兼容型測試、數據抓取與接收的正確性測試，以及本系統對列車門的影響測試。

2.1 總線兼容性測試

本測試目的在于測試本系統在列車總線環境下運行時是否對其它電氣、電子設備造成影響（見表1）。

表1 總線兼容性測試結果

通過以上測試和結果說明本系統在DC110 V電源輸入和RS 485總線的環境下能正常工作，能正確抓取總線中的數據。同時，本系統在正常狀態和自身發生故障的狀態下，均對總線上的其它設備（如門控器）的功能無影響，說明本系統和車門之間沒有相互干擾。本系統對列車總線也不會產生影響。

2.2 數據抓取與接收測試

數據抓取和接收測試主要是測試本系統抓取數據的正確性，以及上傳至遠端監測中心的服務器上數據的正確性。測試項目和結果如表2所示。由表2可以看出，本系統能正確抓取總線上所有正常數據，并且能把數據正確、完整地上傳至監測中心的數據服務器上。

表2 門監測器系統數據抓取與接收結果測試 bit／s

項目組將數據庫中解析出的CDMA Time和數據到達本機的時間Create Time進行比較，如圖5所示。圖5中，CDMA Time表示總線上監聽到數據包的時間，Create Time表示監測中心接收到數據包的時間，LastUpdate Time表示存入監測中心數據庫的時間。可以看出，從總線上監聽數據包到監測中心接收到數據包、存入數據庫的時延均小于1 s。

圖5 數據傳輸時延測試結果

2.3 本系統對列車門的影響測試

本系統在列車未起動、正在起動和運行3個狀態下，對車門的影響進行測試，結果如表3所示。

表3 門監測器對列車門影響測試結果

從表3可以看出，本系統在列車各種狀態下對總線數據沒有任何影響，對車門的各項功能均無影響。

3 結語

軌道交通車門監測系統，通過對車輛系統總線數據的監聽、分析、傳輸，實現了對車門運行狀態及故障信息進行遠程實時監測，使技術人員可以根據系統上傳的信息，分析故障原因，指揮現場工作人員解決問題，保證列車車門的可靠運行。此外，通過上傳的數據，挖掘車門的隱患或亞健康信息，采用狀態維護方式將故障消滅在萌芽中。

［1］劉世豪，劉志剛.地鐵安全性能模糊綜合評價模型及其應用研究［J］.鐵道工程學報，2011（3）：100.

［2］陳斌.串行口數據偵聽實例［J］.計算機應用，1998，18（2）：51.

［3］陳城輝，徐永能，王海峻，等.基于可靠性的南京地鐵車輛維修模式的應用［J］.城市軌道交通研究，2010（11）：84.

［4］王開滿，王軍，張慎明.城市軌道交通自動化綜合監控系統的集成模式［J］.城市軌道交通研究，2007（3）：57.

［5］羅利平.城市軌道交通綜合監控系統集成方案［J］.城市軌道交通研究，2008（11）：7.