摘   要： 網絡化的ATS仿真系統(tǒng)能夠更好地滿足在實際應用中的培訓和教學需求。以上海地鐵2號線ATS(Automatic Train Supervision)仿真系統(tǒng)為例，在系統(tǒng)功能模塊化的基礎之上，結合TCP/IP、UDP協(xié)議和WSAAsyncSelect I/O模型，在現有單機版ATS仿真系統(tǒng)的基礎上設計并開發(fā)了網絡版，使之可以更好地滿足系統(tǒng)的實際應用需求。
關鍵詞： ATS; 仿真; 網絡通信; WSAAsyncSelect

    近年來，軌道交通快速進入高速期，成為帶動經濟增長的重要因素。列車自動監(jiān)控系統(tǒng)(ATS)是一種智能化自動監(jiān)控系統(tǒng)，是否對ATS系統(tǒng)正確操作，影響著列車能否安全運行，這對軌道交通運營管理人員的后勤培訓提出了很高要求。這些綜合性運營專業(yè)人員不僅需要熟悉ATS系統(tǒng)的工作原理，同時還需要具備實際操作能力?？紤]到現場行車安全無法在目前已經投入運營的系統(tǒng)上進行教學培訓，開發(fā)仿真培訓系統(tǒng)就成為解決這一問題的有效途徑，因此ATS仿真系統(tǒng)應運而生[1]。
    單機版ATS仿真系統(tǒng)是運行于單獨一臺主機上并且不與其他主機進行通信的ATS仿真系統(tǒng)，它可以提供模擬演示和故障模擬等基本功能。但是在實際的培訓和教學中，單機版ATS仿真系統(tǒng)仍然存在很多局限性，例如教師無法同時對較多的學員進行示范性操作、無法模擬中央ATS和集中站ATS的拓撲環(huán)境等。這就提出了將現有單機版ATS仿真系統(tǒng)網絡化的需求。網絡版ATS仿真系統(tǒng)是在單機版ATS仿真系統(tǒng)的基礎上，進一步構建基于客戶端/服務器C/S(Client/Server)模型的網絡化通信平臺，著重研究基于TCP/IP協(xié)議下運行在多臺主機上的ATS仿真系統(tǒng)之間的網絡通信。
1 ATS仿真系統(tǒng)網絡版通信模塊的總體設計
    網絡版ATS仿真系統(tǒng)間的通信不同于單機版ATS仿真系統(tǒng)模塊之間的通信，它是基于現有的網絡通信協(xié)議，采用成熟的網絡編程接口實現不同主機、不同進程間的數據傳輸和交互。通過對ATS仿真系統(tǒng)的需求分析，將通信模塊的設計分為組件狀態(tài)同步、客戶端的操作命令傳輸和權限管理三部分進行討論。
1.1 組件狀態(tài)同步的分析與設計
    站場圖上的組件狀態(tài)同步，即將局域網內服務器上組件狀態(tài)的實時數據發(fā)送到客戶端，客戶端根據接收到的實時數據更新組件的狀態(tài)。由于可能同時會有多個客戶端需要接收實時數據，如果采用TCP(Transmission Control Protocol)連接的方式，將消耗很多服務器的資源，導致服務器處理速度變慢，同時也會加重網絡的負擔。并且客戶端并不需要發(fā)送數據給服務器，只要保證接收到的數據的完整性即可，不需要為每一個客戶端建立一個與服務器的TCP連接。所以，綜合考慮上述因素，本文采用UDP(User Datagram Protocol)廣播的方案。UDP廣播具有資源消耗少、傳輸效率高等優(yōu)點，能夠滿足這里的實時通信要求。
1.2 客戶端操作命令的傳輸的分析與設計
       中央ATS起著全局監(jiān)管的作用，一般會把集中站的具體操作控制權交至區(qū)域控制中心。由于區(qū)域控制中心的操作需要被全局看到，包括中央ATS和其他區(qū)域控制中心/集中站，并能夠在中央ATS留下操作記錄。所以客戶端對系統(tǒng)的操作并不是直接作用于本機的系統(tǒng)，而是將操作命令傳給中央ATS，由中央ATS執(zhí)行命令，并將執(zhí)行的結果(如組件狀態(tài)的改變)廣播給所有的客戶端。這樣便可保證區(qū)域控制中心不會越權操作，也可使各個系統(tǒng)之間保持一致。由于客戶端與中央ATS之間的通信屬于端到端的通信，并且需要嚴格保證傳輸數據的完整性，這就需要選擇一個面向連接的、可靠的通信協(xié)議。TCP協(xié)議是一個面向連接、可靠的通信協(xié)議，它通過自身實現的數據確認和超時重傳等機制，保證了數據傳輸的高可靠性，并且客戶端發(fā)送的操作命令的數據較小、在同一時刻也不會有很多客戶端需要與中央ATS進行通信，并不會耗費太多系統(tǒng)資源，所以這里采用面向連接的TCP協(xié)議實現。
1.3 權限管理的分析與設計
    客戶端不僅僅需要作為固定的網絡終端來接收數據，同時也要能夠模擬集中站管理員對系統(tǒng)的操作。主要涉及有：用戶賬號和密碼管理、操作權限的分配和回收、操作權限的驗證和操作命令的代執(zhí)行等。由于數據傳輸量較小，并需要保證數據傳輸的可靠性，故也采用面向連接的TCP協(xié)議實現。綜合以上討論，網絡版ATS仿真系統(tǒng)間網絡通信實現可以用圖1所示的示意圖來表示。

2 網絡通信模塊的軟件實現
    由于ATS仿真系統(tǒng)是一個在Windows平臺基于MFC框架的桌面應用程序，同時需要處理與多個客戶端之間的通信問題，所以在進行具體的軟件實現之前，選擇一個合適的I/O模型尤為重要。在現有的通信模塊中，很多都是基于阻塞模型，其優(yōu)勢在于簡單直接，其缺點在于通常需要耗費較多的系統(tǒng)資源，同時如果涉及到多線程數據交互更是需要進行繁瑣的同步工作。異步通知模型則可以高效解決這種情況下的并行處理問題[2]。WSAAsyncSelect(異步選擇)模型是Winsock提供的一個異步I/O模型，通過這個模型,應用程序可以接收制定套接字上的網絡事件通知，這些異步通知通過窗口消息的方式傳遞。通過對相應消息的處理，應用程序即可實現對網絡連接的控制，最突出的一方面是它可以在系統(tǒng)開銷不大的情況下同時處理許多連接。綜合考慮這些因素，本文采用WSAAsyncSelect模型。
2.1 協(xié)議的設計
    要實現不同主機、不同進程之間的通信，首先要解決進程間的通信協(xié)議設計問題。在網絡化的ATS仿真系統(tǒng)間的通信內容主要是組件狀態(tài)和操作命令兩種。下面就對這兩種傳輸內容分別進行設計。
2.1.1 組件狀態(tài)的協(xié)議設計
    通過對ATS仿真系統(tǒng)的分析，客戶端需要保持與服務器同步所需要的數據有三種：組件的編號(如編號為123的信號機)、組件的狀態(tài)類型(如信號機的顏色)、組件的具體狀態(tài)(如信號機的顏色為綠色)。所以可以將這三種數據整合成一個分組，組件的狀態(tài)編碼的封包格式如圖2所示。

2.1.2 操作命令的協(xié)議設計
   由于操作命令的多樣化，所以將協(xié)議設計成可變的、無固定長度的分組。每一個分組包括命令類型和命令內容。命令內容會因不同的命令類型而有所不同，最后以一個‘\0’作為結束符。這樣既可以方便拆包又能處理TCP數據流中的粘包問題[1]。操作命令的封包格式如圖3所示。

2.2 類設計
   由于服務器端和客戶端的ATS仿真系統(tǒng)都采用WSAAsyncSelect I/O模型，并且都有一些相同的操作，如創(chuàng)建套接字、創(chuàng)建關聯(lián)窗口、關閉套接字等，所以這里封裝一個CATSGenericConnector基類，該基類再分別派生出服務器類CATSServer和客戶端類CATSClient。服務器類實現了Startservice()和Broadcast()等方法，分別用于啟動客戶端等待客戶連接和向客戶端廣播組件狀態(tài)信息?？蛻舳祟悓崿F了ConnectServer()和Send()等方法，分別用于連接客戶端和向服務器發(fā)送操作命令。
2.3 UDP廣播的實現
    UDP廣播主要是為在動態(tài)仿真過程中將服務器上運行的ATS仿真系統(tǒng)的實時信息發(fā)送到每一個客戶端，客戶端根據接收到的數據更新系統(tǒng)上的組件狀態(tài)，以達到與服務器保持同步的目的。服務器在啟動時將設置一個定時器，以一個固定的時間間隔作為一個傳輸周期，在每個傳輸周期內，服務器將改變的組件狀態(tài)按照圖2所示的封包格式進行統(tǒng)一打包，并在一個傳輸周期結束前將封裝好的數據包廣播給局域網內的每個客戶端?？蛻舳藙t單獨開啟一個線程（ListenThread）用于接收服務器端發(fā)送的數據，并對接收到的數據進行解碼，更新相應的組件狀態(tài)。
2.4 TCP通信的實現
        由通信基類CATSGenericConnector派生出的服務器類CATSServer實現了啟動服務器方法StartService()，當服務器對象調用StartService()方法時，服務器創(chuàng)建監(jiān)聽套接字，等待客戶端的連接，并調用WSAAsyncSelect()與仿真系統(tǒng)的窗口關聯(lián)。客戶端調用ConnectServer()與服務器進行連接，并調用客戶端類CATSClient的Send()和OnRead()方法收發(fā)數據。在客戶端連接到服務器之后，服務器會將客戶端的連接信息保存在一個結構ATSClientInfo中，該結構記錄了客戶端的已連接套接字、IP地址、端口號、用戶名和密碼等信息，用于與客戶端進行收發(fā)數據、權限驗證等工作。
2.5 編碼和解碼的實現
    網絡化的ATS仿真系統(tǒng)對傳輸數據的編碼解碼也要分為兩個部分進行討論。首先，對于組件狀態(tài)的傳輸，服務器首先按照圖2所示的封包格式對組件狀態(tài)數據進行編碼，客戶端在接收到數據后對數據進行解碼;其次，客戶端會將操作命令和一些用戶名、密碼等信息發(fā)送到服務器端，由服務器端進行解析、執(zhí)行，這樣就要求客戶端按照圖3所示的封包格式，對所需要發(fā)送的數據進行編碼，服務器對所收到的數據進行解碼、執(zhí)行、驗證權限等操作。
    為了滿足上述要求，定義一個抽象基類，該類聲明了編碼和解碼的接口，具體的接口實現由派生類完成。編解碼類的UML結構如圖4所示。

2.6 測試結果
    在局域網內啟動服務器上的ATS仿真程序，同時在其他多臺主機上的ATS仿真系統(tǒng)上以客戶端用戶登錄，所有客戶端上的仿真程序均能立即收到服務器所發(fā)出的數據，仿真畫面保持一致，沒有出現不一致或者延遲的現象。客戶端的操作亦能準確發(fā)送到服務器上，并且能夠將操作的結果迅速地反映在多臺客戶端上的仿真程序上，測試達到了預期效果。
    本文提出了一個將ATS仿真系統(tǒng)網絡化的方案，以滿足實際應用中對ATS仿真系統(tǒng)的應用需求。該方案綜合考慮了對于仿真同步和模擬中央ATS/集中站等對通信效果的不同要求，分別應用UDP和TCP協(xié)議，并采用基于窗口的WSAAsyncSelect I/O模型，設計并成功地將現有的ATS仿真系統(tǒng)的單機版網絡化，從而有效提高了培訓效率。
參考文獻
[1] 孫志勇, 陳永生. ATS 仿真培訓系統(tǒng)列車模擬運行的設計與實現[J]. 微型機與應用, 2012,31(14):7-9.
[2] 邱俊源, 張躍. 異步消息驅動安全通信模塊的設計與實現[J]. 計算機工程與設計, 2011,32(8):2580-2581.
[3] 賀鵬．城軌列車運行自動監(jiān)控系統(tǒng)的多Agent模型[J]．計算機應用與軟件，2010,27(12)：68-69．
[4] 謝小河, 郭秀清,郭玉臣.基于ATS仿真系統(tǒng)的網絡通信模塊的研究與設計[J].機電一體化，2012(8):53-54.