摘   要： 網(wǎng)絡(luò)化的ATS仿真系統(tǒng)能夠更好地滿足在實(shí)際應(yīng)用中的培訓(xùn)和教學(xué)需求。以上海地鐵2號(hào)線ATS(Automatic Train Supervision)仿真系統(tǒng)為例，在系統(tǒng)功能模塊化的基礎(chǔ)之上，結(jié)合TCP/IP、UDP協(xié)議和WSAAsyncSelect I/O模型，在現(xiàn)有單機(jī)版ATS仿真系統(tǒng)的基礎(chǔ)上設(shè)計(jì)并開(kāi)發(fā)了網(wǎng)絡(luò)版，使之可以更好地滿足系統(tǒng)的實(shí)際應(yīng)用需求。
關(guān)鍵詞： ATS; 仿真; 網(wǎng)絡(luò)通信; WSAAsyncSelect

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

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

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

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

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