日本在线www-日本在线播放一区-日本在线不卡免费视频一区-日本在线不卡视频-成人影院久久久久久影院-成人影院一区二区三区

1.城市地鐵綜合監控自動化系統的應用特點

    地鐵綜合監控自動化系統所有的技術和處理特點都基于其應用特點，這種應用特點主要包括以下幾個方面：
    1.地理分散，集中監控。從監控中心全局看，監控對象分散在沿線甚至多條線的各個車站，操作員站設在監控中心，操作員要集中監控和管理全部車站的所有監控對象；從車站看，監控對象分散在各個專業的設備房，操作員站設在車站綜合控制室，操作員要集中監控和管理本車站的所有監控對象。

    2.處理規模大，事件驅動。一個地鐵綜合監控自動化系統的處理規模如果以I/O點來衡量，至少應支持100，000個I/O點。數據規模的擴大使一般控制系統中常用的周期處理方式變得不再有效，因此“事件驅動”成為地鐵綜合監控自動化系統的主要處理方式。

    3.大量的與第三方子系統或設備進行信息集成，在同一平臺上實現各專業之間的相互協調，相互閉鎖和信息共享。
監控自動化系統的軟件平臺要適應上述應用的特點，在軟件開發的實踐中，著重要解決幾個關鍵技術問題，即軟件體系結構、實時數據庫和系統數據流、接口通信框架和骨干網數據實時性、可靠性設計。

2.基于中間件技術的分層分布式系統結構

    地鐵綜合監控自動化系統的每一個車站都有相對對立的監控系統，監控本站的所有設備，在骨干網中斷的情況下，車站系統不會受到影響并可以作為備用投入運行。中心集中了所有車站的監控，在正常情況下，所有的監控在中心完成。從而形成了中心和車站兩級監控一體化的模式，從物理上骨干網形成了車站和中心的紐帶。這種模式及其地鐵的其它應用特點使得我們在體系結構設計方面將所關心的問題主要集中在基于網絡的跨車站應用集成上，設計具有大規模處理能力的系統。軟件組件可以靈活的部署于一個車站或通過骨干網靈活的部署于車站和中心。

    在本設計中，軟件體系結構設計的關鍵是采用了中間件組件技術。分布在網絡計算機上中間件提供了一個編程抽象，對底層網絡、硬件、操作系統和編程語言異構性的屏蔽。中間件技術的透明分布解決了服務器軟件模塊之間耦合過緊的問題，從而將軟件體系結構從對硬件體系結構的嚴重依賴中解脫出來，將軟件系統從集散型處理過渡到分布式處理。

    在本系統設計中,以客戶形式出現的操作員站應用程序和以資源管理者形式出現的服務器程序使用中間件層進行交互，中間件提供了分布于全線廣域網各節點中對象或進程間的遠程調用。在監控中心，以軟件多機服務器群實現中央服務器的功能。中間件技術的采用，使得系統基本結構由以服務器為中心的集散型結構轉變為以網絡為中心的系統。建立中間件層使得真正的客戶應用專心于應用本身，而不用關心數據來自哪里，也無須考慮網絡層的應用協議。

    基于中間件組件技術的地鐵綜合監控自動化系統軟件結構示意如下圖1：

    中間件的使用解決了操作系統和硬件的不同。雖然在該系統的設計中，UNIX操作系統和WINDOWS PROFESSIONAL 2000操作系統都要實現TCP/IP協議，但它們沒有必要提供相同的協議接口。如UNIX中消息交換的調用方法與WINDOWS PROFESSIONAL 2000的調用方法不同。

3.分布式數據庫和系統數據流

    本設計的實時數據庫以分布形式存在，系統沒有一個實體化的相對集中的數據中心，而是網上多個數據中心。通過“代理”中間件的路徑選擇，使一個地理或功能上分散的系統的全部信息形成一個全局數據庫，任一操作站都可以訪問任何一個服務器，實現本地或遠程的監視和控制。

    中間件技術的采用，同時使得實時數據庫的分布由集散轉向了以網絡為中心，同時數據的上傳和訪問方式也發生了很大的變化。一般原則是域內服務器與I/O站之間采用復制性上傳，而在監控中心服務器與各域之間采用訂閱/發布方式。通過中間件可以訪問系統的任何數據，可以是同步讀寫或訂閱。中間件負責將應用請求定位于可用的服務對象。正常情況下，首先選擇本域服務器，如本域服務器故障，則旁路本域服務器，將請求轉向下一級服務器。同時對服務器的旁路能力也使各級服務器不再成為瓶頸，即使服務器故障，也不影響人機界面對設備的直接訪問。
這種實時數據的訪問模式如下圖2所示：

4.接口通信框架

    不同的現場的設備是通過特定的通信協議接入系統的，因此系統必須實現各種不同通信協議處理的開放性。如果我們能夠構造這樣一種通信協議的開發平臺，使得不同人開發的通信協議處理程序通過一定的固定步驟，方便地集成到系統中來，即通信處理任務的開發者只需要關注通信協議本身，而不必關心數據的應用，那么我們就可以極大的提高通信協議開發的方便性，而且不會影響系統的穩定性。

    要達成上述目標，將I/O站軟件采用層次化結構，將應用層和協議驅動層分開，將會是一種比較理想的解決方案。如圖3所示：

    本設計的關鍵是在將應用層和接口層分開并使得應用層軟件組件保持相對穩定的基礎上，在接口層建立這樣的一種框架，即驅動的公共部分，如動態連接庫、數值工程轉換，跟協議的個性特征分開，使得公共部分保持相對穩定。這種接口框架在集成系統的數據采集層上，協議開發者只要關注通信協議的特有屬性本身，即接口層的通信協議處理層。接口框架還為接口開發提供了統一的格式和步驟，以一致的方式處理通信接口，并為統一的開發模式提供支持。系統針對不同的通信協議，啟動不同的協議處理任務，每個協議處理任務實現自我管理，主動完成對公共部分的鏈接和調用。

    本設計強調I/O站內核和應用的相對穩定性，在這基礎上強調接口編成模式的統一，工程管理的規范，從而實現方便的接入多種子系統或設備的目標。

5.骨干網數據實時性、可靠性設計

    由于新建的地鐵系統中通常建有骨干網，作為地鐵全線所有信息的傳輸通道。綜合監控自動化系統被分配使用其中的一部分帶寬，因此綜合監控自動化系統是骨干網基于寬帶廣域網開發的，并作為整個系統的“內網”，而通信前置機位于各遠方站/子系統，因此來自外部系統的數據實際進入到以骨干網為核心的跨越較大地理位置的分布式數據庫中。為達到系統的實時性、可靠性和數據一致性，本設計中除了底層網絡協議采用了高可靠性的TCP/IP協議外，高層通信協議中還采用訂閱-發布技術。該技術是由客戶應用一次性向本域實時數據庫服務器發出訂閱數據請求，服務器登陸該請求，并周期性將實時數據的最新值發布給客戶，直到客戶應用取消訂閱。當服務器本身不能提供所訂閱的實時數據時，則再向下級服務器或數據源站訂閱，這種逐級訂閱能力使得監控中心操作員站也能讀到最底層的I/O站實時數據。服務器可以歸并應用請求，如當兩個操作員站顯示同一畫面而服務器仍需向下層數據源站訂閱時，相同點數據只發送一次。

    中央服務器是通過動態的訂閱/發布機制向各域服務器請求自己想要的數據，而不是規定全部數據都要上傳。采用這種方式旨在減少通過系統骨干網的無謂的數據傳輸，僅當當前使用的數據才傳上來，從而大大減少骨干網的負荷。這種方式極限情況下才等同與全部數據上傳，通過骨干網的數據流量如下圖4：

6.結論

    軟件體系結構、實時數據庫結構、接口通信框架和骨干網數據實時性、可靠性設計，是城市軌道交通綜合監控自動化系統的關鍵。采用基于中間件組件技術的分布式處理；采用實時分布式數據庫技術，使一個地理或功能上分散的系統的全部信息形成一個全局數據庫；采用I/O站內核和應用的相對穩定性，在這基礎上強調接口編成模式的統一，工程管理的規范，從而實現方便的接入多種子系統或設備的目標；采用逐級訂閱、動態的訂閱/發布機制，提高骨干網數據傳輸的實時性和可靠性等。以上關鍵技術的解決，是開發安全、可靠的城市軌道交通綜合監控自動化系統軟件平臺的基礎。

縮寫：

CORBAR: 公共對象請求代理體系
PSCADA: 電力監控系統
EMCS: 機電設備監控系統
FAS: 防災報警系統
SCR: 車站控制室