前端處理器在綜合監控系統的應用及優化

張大千 熊天圣

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

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

1 FEP的應用

1.1 功能需求

在綜合監控系統中，FEP主要擔負綜合監控系統與各相連子系統的接口管理。通過協議轉換、數據采集和數據下發等功能，完成服務器與子系統設備間的數據交互，從而實現對相連子系統設備的監控。

1.2 功能實現

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

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

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

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

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

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

在整個流程中，通過①→②完成對設備狀態的獲取，通過③→④完成對控制指令的下發;對于不同的子系統，區別只是對數據處理的方式。

1.3 冗余機制

為提高綜合監控系統的可靠性，對其主要硬件配置全部采用冗余機制，FEP也不例外，如圖2所示。

圖2 冗余結構

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

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

2 FEP的應用現狀及優化方案研究

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

2.1 硬件可靠性分析研究

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

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

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

2.2 軟件可靠性分析研究

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

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

2.3 數據通信性能分析研究

當FEP與子系統瞬間數據交互量很大時，FEP的性能肯定會受到一定的影響，輕則造成短時的數據阻塞，重則造成系統出現故障。以接入綜合監控系統的列車監控系統(automatic train supervision，ATS)為例，全線約2000個信息點，按照2次/min數據交換計算，全天交互高達500萬個信息點，這個數據量對任何服務器都是個挑戰。因此，針對這種大數據量的接口設備，從數據傳輸的角度來考慮，采用塊傳輸的效率肯定高于采用點傳輸的效率，但缺點是數據的可讀性會隨之下降。對此，可以采用折中的辦法，FEP采用塊傳輸的方式傳輸數據，數據的解析通過外接維護工作站來實現，調試人員可以在維護工作站上觀察雙方的數據交互情況，這樣FEP本身的負荷會小很多，數據傳輸效率自然會隨之提高。

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

2.4 冗余機制分析研究

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

圖3 ATS數據交互

2.4.1 冗余方式1

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

圖4 冗余方式1

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

2.4.2 冗余方式2

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

圖5 冗余方式2

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

2.4.3 兩種冗余方式結合

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

圖6 冗余結構

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

3 結論

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

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

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

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

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

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

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

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