張大千 熊天圣

(上海寶信軟件股份有限公司 上海 201900)

隨著地鐵的建設，自動化系統(tǒng)被越來越多地應用，各系統(tǒng)間的聯(lián)系也越來越緊密，軌道交通的綜合監(jiān)控系統(tǒng)也就應運而生。由于綜合監(jiān)控系統(tǒng)通過集成眾多的子系統(tǒng)來發(fā)揮整體優(yōu)勢，實現(xiàn)信息互通、資源共享，達到提高運營效率和可靠性的目的，因此對其提出了更高的要求。綜合監(jiān)控系統(tǒng)服務器既要承擔數(shù)據(jù)處理的任務，又要承擔與子系統(tǒng)完成數(shù)據(jù)交互的任務，這將導致服務器需要高配置，同時投資也將增加，還會造成自身負荷過重，當通信量很大時將花費大量數(shù)據(jù)處理時間。為避免上述現(xiàn)象，為服務器端配備了前端處理器(front end processor，F(xiàn)EP)，其主要目的就是完成系統(tǒng)間的數(shù)據(jù)通信任務，降低服務器的負荷，改善服務器的數(shù)據(jù)處理能力，以提高系統(tǒng)的可靠性。

1 FEP的應用

1.1 功能需求

在綜合監(jiān)控系統(tǒng)中，F(xiàn)EP主要擔負綜合監(jiān)控系統(tǒng)與各相連子系統(tǒng)的接口管理。通過協(xié)議轉換、數(shù)據(jù)采集和數(shù)據(jù)下發(fā)等功能，完成服務器與子系統(tǒng)設備間的數(shù)據(jù)交互，從而實現(xiàn)對相連子系統(tǒng)設備的監(jiān)控。

1.2 功能實現(xiàn)

FEP要完成服務器與子系統(tǒng)間的數(shù)據(jù)交互(見圖1)，其功能及原理分析如下。

1)與子系統(tǒng)設備建立通信連接。在物理鏈路連通之后，由FEP主動向設備通信主機請求信息，同時設備通信主機返回應答信息，見圖1中的①。

2)FEP獲取設備狀態(tài)信息，解析并緩存在本地。FEP交互的信息都緩存在本地的實時數(shù)據(jù)庫中，在登錄后可觀察一定時間內雙方交互的原始報文及解析后的數(shù)據(jù)。在系統(tǒng)調試初期，這些緩存的報文可輔助檢測問題;在系統(tǒng)穩(wěn)定之后，可以維護FEP穩(wěn)定高效地運行。

3)服務器端的FEP采取驅動輪詢，采集FEP收集的狀態(tài)數(shù)據(jù)。為建立FEP與服務器的數(shù)據(jù)交互通道，在服務器端安裝了FEP驅動，F(xiàn)EP上傳的數(shù)據(jù)均由驅動分派至服務器相應的寄存器中，見圖1中的②，最終由HMI展現(xiàn)在界面上。

4)控制指令經由FEP驅動下發(fā)至FEP。下置數(shù)據(jù)的順序與采集數(shù)據(jù)的順序相反，會先存儲在服務器端相應的寄存器里，再由FEP讀取后處理，見圖1的③。

5)FEP將控制指令按照協(xié)議格式發(fā)送給設備。FEP在接收到指令之后，根據(jù)接口協(xié)議轉換成正確的報文格式發(fā)送，見圖1中的④。

在整個流程中，通過①→②完成對設備狀態(tài)的獲取，通過③→④完成對控制指令的下發(fā);對于不同的子系統(tǒng)，區(qū)別只是對數(shù)據(jù)處理的方式。

1.3 冗余機制

為提高綜合監(jiān)控系統(tǒng)的可靠性，對其主要硬件配置全部采用冗余機制，F(xiàn)EP也不例外，如圖2所示。

圖2 冗余結構

圖2中的FEP1和FEP2各自獨立運行，與X系統(tǒng)的通信鏈路分別為①和②，且FEP1和FEP2均能同時向服務器1和服務器2上傳數(shù)據(jù)。服務器與FEP之間的鏈路為③～⑥，這樣從服務器到X系統(tǒng)設備間就建立了4條鏈路:鏈路1，①→③;鏈路2，①→⑤;鏈路3，②→④;鏈路4，②→⑥。

當FEP1與X系統(tǒng)(鏈路①)的通信中斷時，服務器1可通過鏈路4獲取X系統(tǒng)的數(shù)據(jù)，服務器2可通過鏈路3獲取X系統(tǒng)的數(shù)據(jù);同理，F(xiàn)EP2故障后，鏈路1和鏈路2可實現(xiàn)數(shù)據(jù)的正常交互，從而實現(xiàn)了冗余切換的功能。

2 FEP的應用現(xiàn)狀及優(yōu)化方案研究

目前，全國各城市已有多條綜合監(jiān)控系統(tǒng)上線運行。從FEP的運行情況來看，易造成通信中斷級別的故障主要集中在硬件方面，如鏈路接頭松動和接口模塊損壞等。除此之外，瞬間大數(shù)據(jù)量交互對FEP性能也有一定的影響，易造成FEP的CPU、內存利用率居高不下或是暫時性的數(shù)據(jù)阻塞等，導致系統(tǒng)功能異常。針對這些問題，應優(yōu)化FEP的設計方案，保證后續(xù)線路不會重蹈覆轍。

2.1 硬件可靠性分析研究

目前，F(xiàn)EP接口模塊只有以太網口和串口兩種，傳輸介質分別為RJ45雙絞線和串口線;無論是哪種端口，對接點的數(shù)量都與故障率的高低成正比。對于使用網口與FEP對連的設備來說，越來越成熟的網絡配線架已將兩者之間的對接方式模塊化，對接的可靠性已達到很高的水平。相比之下，串口基于其特性，接頭處需采用人工接線，穩(wěn)定性相對于網口自然會低一些;但串口的成本較低，在數(shù)據(jù)交互頻率不高的系統(tǒng)中依然得到了很廣泛的應用。盡管如此，串口模塊由于工作時存在電平差，所以當數(shù)據(jù)交互瞬間次數(shù)很高時，發(fā)熱就會很嚴重，造成整個FEP溫度上升，影響系統(tǒng)性能以及設備的使用壽命。

總之，網口和串口模塊各有優(yōu)勢。就地鐵項目而言，由于子系統(tǒng)的功能有簡有繁，對于數(shù)據(jù)量交互很頻繁的系統(tǒng)來說，以太網口是最好的選擇;但對于系統(tǒng)數(shù)據(jù)量交互一般或很少的系統(tǒng)來說，從降低成本的角度出發(fā)，可選擇使用串口模塊。因此，在接口設計初期，可通過預估數(shù)據(jù)交互頻率、數(shù)據(jù)量大小和用戶對鏈路的日常維護要求，確定接口模塊的類型。

FEP硬件能夠同時支持多種通信接口模塊，即支持很多的網口和串口同時運行。因此，為防止因地址混亂而造成的通信故障，在操作系統(tǒng)安裝時就應為每個端口規(guī)劃其相應的地址，實現(xiàn)網絡隔離。除此之外，還需要保證各功能模塊具有自診斷和自恢復的功能，保證鏈路恢復后通信能夠自行恢復。

2.2 軟件可靠性分析研究

在FEP與子系統(tǒng)連接建立的初期，F(xiàn)EP會按照雙方約定的協(xié)議來檢測第一個通信模塊，待雙方正常通信后，再按照這個步驟來逐個檢測剩下的通信模塊，直到初始化過程完畢，F(xiàn)EP的各模塊才開始輪詢采集子系統(tǒng)設備信息，并緩存在本地的寄存器中，實現(xiàn)通過協(xié)議轉換獲取設備信息的功能。

由于雙方通信連接的保持是通過不斷地收發(fā)報文來實現(xiàn)的，而報文是由程序按照協(xié)議格式封裝而成的，所以協(xié)議本身就是報文穩(wěn)定性的一個關鍵。根據(jù)系統(tǒng)功能定制開發(fā)的協(xié)議，交互報文的穩(wěn)定性相比標準協(xié)議規(guī)定的穩(wěn)定性要低得多。雖然在數(shù)據(jù)交互時允許報文出錯，且接收方可以根據(jù)錯誤校驗丟棄報文，但是浪費了帶寬資源。因此，從通用性和易維護性方面來考慮，協(xié)議的商定應盡量選擇標準的類型，以減少由FEP定制開發(fā)所產生的不必要錯誤。同時，當FEP與設備的鏈路遭遇通信中斷的問題時，對不同的系統(tǒng)應有不同的處理方式;對信息實時性要求較高的系統(tǒng)，在遇到連接中斷或阻塞等情況時，F(xiàn)EP必須具備丟棄報文的功能，如廣播系統(tǒng)(public address，PA)、導乘信息系統(tǒng)(passenger information system，PIS)、門禁系統(tǒng)(access control system，ACS)等;對信息完整性要求較高的系統(tǒng)，F(xiàn)EP必須在本地緩存這些指令，待鏈路恢復后繼續(xù)交互，如電力監(jiān)控系統(tǒng)(power supervisory control and data acquisition system，PSCADA)的事件順序記錄(sequence of event，SOE)等。

2.3 數(shù)據(jù)通信性能分析研究

當FEP與子系統(tǒng)瞬間數(shù)據(jù)交互量很大時，F(xiàn)EP的性能肯定會受到一定的影響，輕則造成短時的數(shù)據(jù)阻塞，重則造成系統(tǒng)出現(xiàn)故障。以接入綜合監(jiān)控系統(tǒng)的列車監(jiān)控系統(tǒng)(automatic train supervision，ATS)為例，全線約2000個信息點，按照2次/min數(shù)據(jù)交換計算，全天交互高達500萬個信息點，這個數(shù)據(jù)量對任何服務器都是個挑戰(zhàn)。因此，針對這種大數(shù)據(jù)量的接口設備，從數(shù)據(jù)傳輸?shù)慕嵌葋砜紤]，采用塊傳輸?shù)男士隙ǜ哂诓捎命c傳輸?shù)男剩秉c是數(shù)據(jù)的可讀性會隨之下降。對此，可以采用折中的辦法，F(xiàn)EP采用塊傳輸?shù)姆绞絺鬏敂?shù)據(jù)，數(shù)據(jù)的解析通過外接維護工作站來實現(xiàn)，調試人員可以在維護工作站上觀察雙方的數(shù)據(jù)交互情況，這樣FEP本身的負荷會小很多，數(shù)據(jù)傳輸效率自然會隨之提高。

從數(shù)據(jù)處理的角度來考慮，對于不需經過服務器處理的數(shù)據(jù)，最好由FEP直接協(xié)議轉換并轉發(fā)，以降低中轉的環(huán)節(jié)，提高整個綜合監(jiān)控系統(tǒng)的工作效率。圖3(a)是某地鐵綜合監(jiān)控系統(tǒng)ATS信息轉發(fā)PIS的方案:FEP在接收到ATS上傳的數(shù)據(jù)之后，將數(shù)據(jù)傳輸至服務器進行處理，再將數(shù)據(jù)返回給FEP，由FEP傳輸至PIS系統(tǒng)，整個流程一共要進行4次數(shù)據(jù)收發(fā)。圖3(b)是FEP具備協(xié)議轉換功能之后的優(yōu)化方案:ATS的數(shù)據(jù)上傳至FEP后，直接由FEP轉發(fā)給PIS系統(tǒng)，中間減少了2次數(shù)據(jù)收發(fā)，不僅減少了系統(tǒng)的故障點，而且還提高了系統(tǒng)的可靠性。因此，F(xiàn)EP今后的發(fā)展一定要越來越適應這種大數(shù)據(jù)量的接口設備。

2.4 冗余機制分析研究

綜合監(jiān)控系統(tǒng)的接口數(shù)量多，接口方式也多種多樣，因此接口性能的穩(wěn)定是綜合監(jiān)控系統(tǒng)與子系統(tǒng)之間保持正常通信的關鍵，但接口設備不可能達到100%的無故障率。當系統(tǒng)間的某個部件發(fā)生故障時，可通過備用部件進行正常的數(shù)據(jù)收發(fā)，使系統(tǒng)的可靠性得到保障，這就是目前提高系統(tǒng)可靠性最普遍的做法——冗余切換。每個綜合監(jiān)控系統(tǒng)采用的冗余機制都不盡相同，但都有共同的目的，就是在系統(tǒng)結構更簡單的同時，冗余的可靠性更高。

圖3 ATS數(shù)據(jù)交互

2.4.1 冗余方式1

目前的FEP采用設備級的冗余機制居多，如圖4所示。

圖4 冗余方式1

FEP通過計算與其通信正常的子系統(tǒng)數(shù)量來設置冗余標志位，多的設置為“主”，少的設置為“備”。當FEP1與A子系統(tǒng)的通信中斷之后，F(xiàn)EP1通過其內部的交換機卡1連接FEP2的交換機卡2，完成與A子系統(tǒng)的通信建立，實現(xiàn)冗余切換。這種機制的FEP結構較為復雜，內部需配置交換機卡，其實現(xiàn)難度主要集中在兩臺FEP之間的路由轉換，因此被稱為“基于FEP本身的冗余”。

2.4.2 冗余方式2

從綜合監(jiān)控系統(tǒng)建設的角度來看，在冗余功能相同的前提下，整體方案應越簡單越好。因此，通過將冗余取決權上交至服務器端FEP驅動的方式，替換FEP內部交換機卡所完成的任務，實現(xiàn)冗余功能，被稱為“基于上位驅動的冗余”，如圖5所示。

圖5 冗余方式2

FEP1和FEP2相對獨立，內部不需要配置交換機卡，但FEP要將與每個子系統(tǒng)的連接狀態(tài)傳輸給上位的FEP驅動，由FEP驅動根據(jù)端口通信情況來決定鏈路。如圖5所示，當FEP1與A系統(tǒng)連接中斷、FEP2與B系統(tǒng)連接中斷時，上位驅動就會選擇FEP1的B系統(tǒng)和FEP2的A系統(tǒng)作為通信鏈路，實現(xiàn)冗余功能。這種機制的FEP結構較為簡單，其實現(xiàn)難度主要集中在上位FEP驅動的開發(fā)。與方式1相比，這種機制的優(yōu)點就是結構簡單，由于內部環(huán)節(jié)比較少，所以維護起來也方便。

2.4.3 兩種冗余方式結合

FEP畢竟屬于獨立設備，服務器無法直接檢測端口的真正狀態(tài)，所以可將兩種方式結合起來，如圖6所示。

圖6 冗余結構

在兩臺FEP之間建立一條心跳連接，通過“心跳線”，F(xiàn)EP就能了解彼此子系統(tǒng)端口的狀態(tài)，然后以寫入配置文件的方式，指定上位的FEP驅動和哪臺FEP的子系統(tǒng)交互數(shù)據(jù);只有當“心跳線”中斷之后，取決權才上交由上位FEP驅動來選擇，這樣FEP原有的冗余功能才不會缺失，且提高了多點故障時的數(shù)據(jù)可靠性。

3 結論

FEP的發(fā)展需要跟隨綜合監(jiān)控系統(tǒng)未來的走勢。未來綜合監(jiān)控子系統(tǒng)集成化會越來越高，這也就要求FEP的功能越來越強大，不僅要具備通信的功能，而且還要具備簡單數(shù)據(jù)處理的功能。另外，系統(tǒng)易維護性的提高也是重中之重的任務。

［1］黃昱旻.地鐵綜合監(jiān)控系統(tǒng)結構研究［J］.現(xiàn)代城市軌道交通，2009(4):21-23.

［2］李中.地鐵綜合監(jiān)控系統(tǒng)應用技術研究［J］.城市軌道交通研究，2008(10):44-47.

［3］胡澤盛.廣州地鐵主控系統(tǒng)接口冗余通信分析［J］.都市快軌交通，2009，22(6):86-89.

［4］劉麗.軌道交通綜合監(jiān)控系統(tǒng)的網絡設計［J］.都市快軌交通，2010，23(6):40-43.

［5］張慎明，王軍.新一代綜合監(jiān)控系統(tǒng)若干問題的研究和探討［J］.現(xiàn)代城市軌道交通，2010(1):18-21.

［6］姜臻祺.適合軌道交通綜合監(jiān)控系統(tǒng)(ISCS)運營組織體系相關問題的探討［J］.地下工程與隧道，2009(4):43-45.

［7］謝金華.對城市軌道交通綜合監(jiān)控系統(tǒng)方案的闡述［J］.建材與裝飾，2010(7):252-253.