通信協議在鐵路防災監控系統中的應用研究

楊小軍 徐 昆

楊小軍:同方威視技術股份有限公司 工程師 100084 北京

徐 昆:昆明鐵路局工務處 高級工程師 650011 昆明

在我國山區，危巖落石是三大自然災害之一，嚴重影響了鐵路列車在山區的安全運行，成為制約我國西部開發和交通建設大發展的重要因素。因此，展開落石監測的鐵路防災監控系統研究，對保證山區鐵路列車安全運行具有十分重要的現實意義。

1 鐵路防災監控系統概要

鐵路防災監控系統可以分為數據采集層 (包含現場采集設備及監控單元)、數據處理分析層(包括數據庫服務器及應用服務器等)和數據展示層 (包括工務終端及調度終端等)，系統架構如圖1所示。

在鐵路防災監控系統中，現場監測設備呈現多樣化，為了保證所有現場監測設備的正常運行，每個現場設有一個監控單元。如何讓數據處理中心與所有現場監控單元保持實時、可靠的連接，對現場監測及現場維護具有重要的意義，因此研究一種高效、可靠、可擴展且適用于鐵路防災系統的通信協議十分必要。

2 通信協議方案

在現有的鐵路防災監控系統中，現場監控單元與數據處理中心連接大多采用通用組態軟件、OPC或者通用通信協議 (如modbus協議)，采用以上通信方式的優缺點如下。

優點:通信協議開發簡單，現場監控單元有可用的通信包可以調用，無需進行復雜的通信協議編程;數據處理中心的監控軟件無需開發，可直接購買通用組態軟件。

缺點:由于通用組態軟件的限制，不利于對數據處理中心的算法編程、畫面繪制等;組態軟件中的通信驅動無針對性，通信效率不高;通信協議缺乏直接開放的接口，不利于系統的有效擴展;當監控現場的硬件發生改變時，通信協議及上層監控軟件也要隨之修改，不利于系統的維護。

在針對落石監測的鐵路防災監控系統中，通信效率、算法分析及畫面展示是整個系統的技術關鍵，因此繼續采用通用組態軟件或者通用通信協議方式已經不再合適。根據系統要求，比較合適的方式是采用自由通信協議，自定義協議格式、連接模式、硬件程序架構等，可設計出高效、可靠、擴展性良好的通信協議。

圖1 鐵路防災監控系統架構圖

3 通信協議的開發

在防災監控系統中，監控主機單元負責整個系統中所有設備 (包括工控機、PLC控制器、UPS電源、低壓電器、傳感器等)的監控。當設備出現故障時，如何向數據處理中心進行報警;當設備出現故障時，如何來定位故障點;如果數據處理中心需要對設備進行控制時，如何傳遞控制命令。這些信息 (包括故障報警、控制命令等)的傳遞都需要一套約定來實現，因此需要一套脫離物理層的通信協議。

3.1 可擴展的協議格式

既有鐵路防災監控系統中，鐵路防災的報警信息較為有限，主要包括風、雨、雪、異物等。為了使新設計的鐵路防災監控系統數據能夠兼容其他防災系統數據，該通信協議在格式上留有接口。同時，考慮到以后系統的擴展，該通信協議還需具備一定的開放性及可擴展性。擴展性出于2種目的:首先是有利于建立統一的防災體系，為有效整合現有的鐵路防災系統打下基礎;其次是有了統一的數據基礎后，為后續的數據挖掘和分析打好基礎。通信協議的格式定義好后，數據處理分析系統即可根據此規則對所有鐵路防災數據進行處理分析。

經過綜合研究，可擴展的協議格式定義如圖2所示。報頭，代表鐵路防災監控數據專用，用“AA”表示;報文種類，是“上傳”還是“下達”的數據，通過這個字節來區別;報文類型，包括各種命令種類，如故障、報警、命令等;報文數據，是對各種報文類型的補充，代表著真正的報文含義;校驗，是對整個報文進行校驗，以保證報文在傳輸過程中的可靠性。在該通信協議中，報文類型、報文數據均可根據需要進行擴展，滿足各種鐵路災害數據的傳遞。

圖2 通信協議的格式定義

3.2 高效可靠的通信模式

通信系統采用客戶端和服務器的通信模式。以TCP/IP為例，通信套接字調用的順序如圖3所示。上位機PC端作為“客戶端”主動連接“服務器”PLC端。PC端主動發起通信socket連接命令，而此時PLC作為服務端 (監聽端口)一直處于等待連接狀態，直到通信連接成功。

圖3 通信套接字調用的順序

連接成功后，上位機立刻發送“初始化幀”，此時PLC也在等待上位機發送初始化命令。初始化成功后，上位機負責通信連接的保持，如果2 s內上位機沒有收到任何數據幀，則啟動“hello報文”的發送。 “hello報文”由PC端發送給PLC，每隔2 s發送一次，上位機每隔200 ms判斷一次是否有所發報文的回復，若無回復則繼續發送“hello報文”，如果連續3次發送都沒有返回，認為連接中斷，此時上位機需要重新初始化才能繼續進行通信;如果200 ms判斷有回復，間隔2 s再次發送hello報文，如此循環來保持通信連接。

在通信連接正常時，如果現場設備有報警，作為監控核心的PLC立即生成相應的報警報文，并通過以太網口向數據處理分析中心發送，整個過程在1 s內完成。同理，當上層有控制命令需要傳送給現場設備時，也能在1 s內將命令傳送給現場設備。由于采用了hello連接模式，當通信異常時，上層系統能立即發出報警，保證了通信的可靠連接。

3.3 不依賴硬件的程序架構

通信協議的設計重點是滿足監控主機單元與上層的通信連接，實時監控鐵路沿線復雜的設備狀態。然而，對鐵路防災監控系統而言，監控核心一般采用穩定可靠的PLC(可編程控制器)，其功能并不像計算機那么強大，不能使用高級語言來編寫程序，因此，為了使整個通信協議結構清晰，且便于通信程序的編寫，對程序架構進行了分層設計。整個通信協議的架構分為3層，各層的功能如圖4所示。無論采用何種監控核心 (西門子、施耐德或貝加萊)，均可采用這種架構進行編程，提高通信協議的兼容性，有利于系統的擴展。此外，通信協議不依賴物理層，無論使用RS-232、RS-485還是TCP/IP通信接口，該通信協議都可在此基礎上應用。

圖4 通信程序架構圖

4 通信協議的測試結果

以西門子S7-300型號PLC為例，編寫一套通信程序來完成各項通信協議功能。SIMATIC S7-PN核心包含一個集成PROFINET接口，具有TCP通信功能。通過該集成以太網接口組態TCP通信，只能使用開放式通信專用的功能塊。依據RFC793的TCP協議，在STEP7通信塊的標準庫中提供了一些FB功能塊，通過用戶程序與符合以太網標準的通信伙伴進行數據交換。

編程實現測試結果如圖5所示。輸入PLC的IP地址進行通信連接，通信連接成功后，上位機開始發起“hello包”的連接。當無數據交換需求時，系統通過“hello包”來維持上位機和下位機的連接;當有數據交換請求時，如下位機有“故障報警”請求，此時下位機會以通信協議定義的格式生成一條數據幀發送給上位機，上位機接收成功后給予回復，表明“故障報警”已收到。同理，如果有其他數據幀的交換，也是按照此規則進行。

圖5 編程實現測試結果

5 結束語

通過建立一套穩定可靠的通信協議，對整個系統的所有設備運行提供了實時、可靠的監控，并且當設備故障需要維修時，通信協議可提供方便、準確定位、可視化的維護維修接口。同時，由于通信協議具備良好的開放性及可擴展性，為將來建立統一的防災體系，有效整合現有的鐵路防災監控系統打下基礎，并為后續的數據挖掘和分析打下良好的基礎。

［1］ 張新芳．高速鐵路、客運專線防災安全監控系統設計探討［J］．鐵道工程學報，2006(4):71－74．

［2］ 王玉鎖．高速鐵路隧道洞口段危巖落石運動軌跡及沖擊特性研究［J］．前沿動態，2011(2):16－18．

［3］ (美)科默(Comer，D．E)著．計算機網絡與因特網［M］．北京:機械工業出版社，2009:22－23.