?
列車調度指揮系統(TDCS)是實現鐵路各級運輸調度對列車進行透明指揮、實時調整、集中控制的現代化信息系統,它由鐵道部、鐵路局中心局域網及車站基層網組成。TDCS車站分機是車站基層網的設備,起到信息的采集、上傳及下發的作用,在整個系統中占有非常重要的地位。
1 功能分析
在車站分機系統中,車站分機軟件主要實現兩個方面的功能:
(1)接收鐵路局調度中心和車務終端的調度命令,經過命令解析處理后,經無線調度命令設備發送至列車執行;
(2)接收計算機聯鎖設備、無線車次號設備、無線調度命令設備發送的狀態信息,經過解析和重新封裝后,將狀態信息發送到鐵路局調度中心和車務終端。
由以上分析可知,系統主要有以下3個功能模塊:接收狀態模塊、接收命令模塊和數據處理模塊。其中,接收狀態模塊由RS 422串口通信方式實現;接收命令模塊由以太網通信方式實現;數據處理模塊主要負責數據的處理和發送。
2 多任務模型的創建
基于Windows操作系統,針對上述3個模塊,本文分別建立了3個任務:串口通信任務、以太網通信任務、數據處理任務。其中數據處理任務作為主線程,包含數據的接收與上傳,其處理過程如下:
(1)接收線程收到數據,放入緩沖區,并用PostMessage()向主線程發送消息,通知主線程有數據存入緩沖區;
(2)主線程使用ReadFile()函數讀取緩沖區數據;
(3)主線程判斷收到的數據是否有變化:若有變化,調用WriteFile()函數或SendData()函數發送消息,并將定時器清除;否則,繼續等待。數據處理任務的具體流程如圖1所示。
?
在該系統中,使用AfxBeginThread()函數創建以太網通信任務、串口通信任務和數據處理任務之后,用消息機制實現了多任務之間的通信,而用信號量、互斥等方式實現了線程之間全局變量和函數的同步。
3 通信協議設計和解析
協議是數據發送與接收方都必須遵守的一種規則,這種規則一部分是發送方及接收方所認識的信息組成格式即信息結構,另一部分是由信息結構的協議類型及協議操作符所組成的會話方式即傳輸控制。
在該系統中,從串口和以太網接收到的各種的數據的類型和長度是不一致的,數據處理任務要對其分門別類進行處理就必須明確數據的類型、實際長度以及數據本身。因此必須定義一種數據傳輸的協議以保證通信的可靠性和數據讀取的可用性。本文針對以太網通信和串口通信,分別建立了對應的數據協議。
3.1 以太網通信協議
以太網通信涉及的信息包括計算機聯鎖設備狀態信息、無線車次號信息、調度命令信息。本文定義了一種以太網信息通用的數據協議封裝類如下:
?
在該數據結構中,報文類型用來識別該報文是聯鎖設備信息、無線車次號信息或者調度命令信息;序列號用來判斷接收報文的連續性;CRC錯誤檢測綴用來判斷接收報文的正確性,可以根據需要選擇不同的生成多項式;接收數據數組將根據聯鎖設備信息、無線車次號信息和調度命令信息的相應內容填充。
3.2 串口通信協議
串口通信采用RS 422方式。在嵌入式車站分機中,冗余的處理器單元采用輪詢的方式進行一主多從通信。車站分機作為主機,無線車次號設備、無線命令調度設備和計算機聯鎖設備作為從機。具體為:使用1問1答的方式,整個系統中車站分機發送查詢命令,其他設備是從機,只能被動地接收和發送數據。
在串口通信中,必須為每一個數據報文設計一個起始碼和結束碼,如0x03,并對報文中所有與起始碼和結束碼相同的字符進行轉義。接收方接收到該報文時,再按照轉義規則對其進行還原。本文定義的通用串口數據協議封裝類如下:
?
其中:報文類型、序列號和CRC錯誤檢測綴的作用與以太網通信協議相同;從機地址用來區分該報文的目的地是無線車次號設備、無線調度命令設備還是計算機聯鎖設備。
查詢命令的數據格式如表1所示。
?
3.3 自定義協議的解析及應用
對于從設備讀取來的數據如何才能正確按照上述協議分析并使用,則必須設計相應的分析算法進行分析并處理。在此設計了一個數據分析類來進行處理:
?
?
數據接收和分析基本流程:數據接收任務調用數據分析類的Write()函數,將接收到的數據寫入數據分析類緩沖區;數據處理任務調用數據分析類Read()函數讀取數據分析類緩沖區的數據進行處理,讀取的規則是按照數據協議格式來讀取。它的基本流程如圖2所示。
?
4 結語
在Windows平臺下,應用程序開發人員可以利用它提供的多任務機制開發具有并發需求的軟件系統,它的多任務機制允許多個進程和多個線程同時執行。
車站分機通信軟件就是在此基礎上開發的;協議是數據發送與接收方都必須遵守的一種規則,在該系統中,從串口和以太網接到的收數據格式不一致,如果不對其進行統一的數據格式打包,在傳輸大量的數據和進行超時及異常處理時,就必須進行繁瑣的編程。本文中自定義了協議包的信息結構,并給出了它的解析算法,在通信軟件中起到了化繁為簡的作用。
評論
查看更多