3 地鐵綜合監控系統軟件分析

    地鐵綜合監控系統的運行環境是由硬件、軟件和數據三個主要部分的有機組成。其中硬件包括各類計算機、網絡設備、通訊鏈路和各類基礎自動化層設備（如PLC）等；軟件通常包括操作系統、支撐軟件和應用軟件，其中支撐軟件往往被軟件開發商集成在應用軟件中。數據則指支持系統運行的環境配置，典型的如繪制的人機界面、監控對象的定義、通訊參數等，隨著“組態”概念的引入，系統承建商在工程階段的配置數據已不僅局限在定義和配置靜態數據，也包括定制系統的某些特定行為甚至開發一些新的功能上，因此廣義地看，由于數據完全反映了系統設計的內容，也可以歸入軟件的范疇，這和目前地鐵界的普遍看法是一致的。也就是說，除了硬件設備大部分是采購的，其余的系統集成部分都是屬于“軟件開發”。

    如何來選取、如何認識綜合監控系統軟件呢？顯然針對每個項目都進行一遍完整軟件的開發過程是不現實的。根據大系統開發經驗，即使在具有相當的技術積累基礎上開發一個地鐵監控系統軟件至少需要100人/年，其中穩定期一般至少應在1.5~2年，這樣對工程而言，不僅時間上等不起，全新的東西一般也不敢用。因此無論系統集成商還是業主都會選擇一個相對成熟的、適用的應用軟件平臺，在這個平臺的基礎上進一步開展面向具體應用需求的應用開發。

    一般來講，這個應用軟件平臺應該至少滿足以下要求：

    （1）是一個經過高度功能抽象的通用自動化監控系統軟件，采用分層分布式架構，實現自動化監控所必須的對各種底層設施的監控、管理功能。軟件必須具有實時數據庫、通用HMI、報警/事件系統、日志系統、歷史數據庫、報表系統、權限管理、部件冗余和診斷等。

    （2）具有開放性，具備支持后續開發的擴展機制，包括腳本系統、應用開發工具和代碼級開發的程序庫，以及基于一定標準的系統訪問接口，能嵌入或可以外掛新開發的軟件模塊和定制應用功能。

    （3）由于地鐵是一個地理分散的廣域系統，軟件必須具有SCADA的遠動功能，即從OCC下行的遙控命令須在2秒內到達，返信時間也應在2秒之內。這樣，才可順利完成地鐵運營要求的每天的順控上電和晚間停電。最好也能具備遠程維護能力。

    （4） 支持系統規模擴充和分期施工。

3.1 兩類地鐵綜合監控軟件

    目前在地鐵綜合監控系統中出現的應用軟件平臺產品形態上大體可以分為兩類。一類是獨立軟件廠家(ISV)的商品化軟件，另一類是由系統集成商提供的軟件。

    商品化軟件主要是各種工控組態軟件，國外國內都有很多，較成熟，廣泛用于各類工業控制和監控場合，其最大優點是HMI功能支持豐富、結構擴展靈活，開放性好，因此具有很強的適應性和通用性。但也正由于這一產品通用性定位使得工控組態軟件對目標領域的監控特點缺乏針對性，缺少地鐵運營要求的功能，尤其不能滿足上述的地鐵應用軟件平臺必須滿足的4條要求中第三條要求和第一條中的要求。這些軟件不作針對地鐵應用的開發是難于在地鐵綜合監控系統中成功應用的。直接使用一個組態軟件僅僅通過組態通常是達不到地鐵綜合監控多種專業的功能要求的，這就需要系統集成商對組態軟件進行一定的改造，包裝成地鐵適用的軟件平臺，最典型的如增加遠程控制和設備管理功能。由于知識產權原因，通常這種改造是通過嵌入、替換和外掛新的軟件模塊實現的。但是，這種開發又需經過在地鐵綜合監控的成功應用加以檢驗，系統集成商如果是第一次進行開發又無在地鐵做綜合監控系統的經驗，將會給工程帶來極大風險。

    由系統集成商或工程公司開發的軟件平臺一般與領域監控特點和功能要求更為接近，并具有長期從事這一領域的工程基礎，因此其軟件功能的設置、體系結構等方面更適合地鐵綜合監控系統的構成、運營和維護的要求。只是產品化形態方面可能稍差。由于工程公司并不以軟件產品外賣為目標，如果工程公司本身作為系統集成商參與工程這一缺陷對最終用戶的影響不大，但如果僅作為軟件供貨商供其他系統集成商使用，也會給工程帶來風險。

    進一步分析，如果把這兩類軟件對應看待，組態軟件所提供的設計界面更低更基礎，應屬于可用但不適用的綜合監控系統軟件平臺；如果有地鐵運營經驗的系統集成商經過軟件開發把組態軟件和附加的行業性應用功能合并，構成一個面向行業應用并集成了組態軟件的應用平臺，那么，可以構建起成功的地鐵綜合監控系統軟件平臺。這種做法符合現代的軟件開發方針——開放系統加COTS（貨架上的商用軟件）。但是這種開發綜合監控軟件平臺的做法也需要假以時日，并受到組態軟件本身系統支撐能力的限制，可能花了較大的開發成本，得到的是一個局限性較大的綜合監控軟件平臺。

    由國外系統集成商開發的綜合監控軟件雖說可以適應地鐵綜合監控要求但性能差異較大，特別是對國內的工程的適應性較差，例如許多軟件平臺并不滿足前述的第三項要求，遠動性能指標不滿足我國電力規范要求。另外，作為軟件供貨商他們的服務水平遠不及國內的系統集成商，會給工程帶來潛在的損失。由上可見，現在一些地鐵工程專門限定必須采用國外軟件平臺，而且要求僅作軟件供貨商的國外廠家在技術上負責會給工程帶來多大的風險！

    目前一些有綜合監控工程實施經驗的系統集成商正在將具與自主技術的綜合監控軟件平臺在工程實踐的歷練中通用化、產品化，這類新的綜合監控軟件平臺克服了上述兩類軟件的不足，必將得到良好發展。

3.2 國內外地鐵綜合監控系統軟件平臺比較

    由國外綜合監控系統系統集成商以軟件供貨商身份提供的地鐵綜合監控軟件、軟件功能的設置、體系結構等方面可適合地鐵綜合監控系統的構成和運營、維護的要求。但產品化形態較差，面對每一個工程度都要重新設計、組態、甚至開發，因此價格很高。為了從本質上認識國外綜合監控軟件作出如下的分析研究。

    二十世紀九十年代，國際上就已出現了地鐵綜合監控系統軟件稱為ISCS軟件。這種型態的軟件是以中央監控中心（OCC）信息集成為核心，平臺延伸到車站監控層通過其前端處理器（FEP）將車站的各子系統接入構成信息共享平臺。一般來講，這類系統在系統頂層（OCC）設有電調、環調、行調、維調和總調中心，軟件平臺將車站各自獨立的子系統（各不相同的軟件平臺）的信息采集到一起，在OCC和車控室實現綜合監控功能。國內有人稱之為頂層信息集成的綜合監控系統。法國泰蕾茲公司在香港將軍澳線和新加坡東北線采用了這樣的綜合監控系統。頂層信息集成的綜合監控系統軟件是在OCC和車站的監控層將部分子系統集成和互聯起來構成綜合監控系統。雖然，這類軟件平臺在橫向上幾乎不受限制，可以按照用戶的意愿連接較多的子系統，系統的范圍較大，可實現信息共享，實現綜合監控功能，但在縱向將原來分立的子系統分為兩個不同軟件平臺支持的兩部分，在車站將被集成子系統截為兩截，對于地鐵的一些具有SCADA特性要求的子系統，會大大地降低系統的運動性能，例如，電力系統遙控時間將大于3.5秒超出電力規范對遙控時間的要求。此外，這類軟件平臺由于在車站實行兩個軟件平臺對接，給調試、故障診斷和維護帶來極大工作量。早期國內外出現的綜合監控系統皆采用此類平臺，目前，國外供貨商推崇此類軟件，但會給國內系統集成商帶來極大麻煩，如果國內系統集成商沒有綜合監控系統的實施經驗甚至會給工程帶來危害，完工后的系統將達不到合同的一些重要技術要求。一些二線城市的新開的地鐵工程應特別注意此問題。

    目前由國內系統集成商開發的綜合監控系統軟件以滿足地鐵運營要求為主導，強調對工程的適用性，為了滿足前述的4點要求，采用了深度集成方式，即用同一軟件平臺將被集成子系統從頂到底完全融入綜合監控系統中，不會在車站出現兩個軟件平臺對接的根本性問題。因而，其實施性能極好。

    更為重要的是國外軟件平臺的供貨商采用的大都是二十年前開發的軟件，對于這些軟件由于人力成本的昂貴也很少再進行修改、升級。軟件平臺的質量并非像有些人所迷信的那樣，許多國內的工程實踐已證明了這一點。而國內的軟件供貨的系統集成商具有自主的開發能力，采用了較新的軟件技術和先進的軟件設計理念，同時不斷地修改、優化、升級。系統集成商具有自主知識產權的軟件平臺是工程成功的最可靠保證。

    表1是國內外綜合監控軟件平臺的一個簡單比較，結論不言而喻。

                             表1   國內外綜合監控軟件平臺比較

	國內深度集成綜合監控系統軟件平臺	國外頂層信息集成綜合監控系統軟件平臺
結     構	簡約型結構，層次優化，對硬件的要求簡單	車站層層次冗繁，降低了系統性能，對硬件的要求較高
系統響應性	數據頂層至底層〈1秒，底層至頂層〈2秒	數據頂層至底層〈2秒，底層至頂層〈3-4秒
系統有效性	99.98%	99.98%
系統集成度	一體化的軟件將被集成子系統綜合為一個系統	車站被集成子系統分別為獨立的系統具有與綜合監控系統不同的軟件平臺；
系統實施性能	系統實施便捷，可實現一次調試成功，故障 診斷簡易，系統維護方便	進行工作量巨大的對點表工作，調試、故障診斷、系統維護極不方便；
系統總價	為國外頂層信息集成系統的40%-50%	昂貴
擴展與增值服務	良好，費用較低	較差，價格高

3.3 綜合監控軟件平臺的本質要求

    綜合監控軟件平臺在發展過程中，使開發者和用戶認識到了一些對它的性能的最本質要求，以下將對這些要求進行闡述。

3.3.1 綜合監控軟件平臺的開放性要求

    綜合監控系統軟件平臺應通過采用開放的軟件架構和標準的軟件組件，實現為一個具有可伸縮性的軟件系統。軟件的構成應獨立于硬件配置，支持多種硬件結構，可按照項目的具體硬件配置進行工程設計和部署，以滿足具體的功能要求，使得系統整體性能優異。

    系統軟件應支持服務器集群，數據庫的分布獨立于硬件配置架構，單臺服務器使用的每個本地數據庫可以只是全局數據庫的部分映像，整個數據庫是所有這些邏輯片段的合并。當數據庫分布運行在多臺服務器時，系統具備自動的數據路由功能，對工作站的數據訪問沒有任何影響。

    綜合監控系統軟件平臺應建立在COTS（Commercial -Off-The-Shelf，商用現貨）軟件基礎上，通過選擇成熟、開放的COTS軟件作為構成系統軟件的基礎，使綜合監控系統軟件具有良好開放性。

    綜合監控系統開放系統宜采用面向對象的系統，它要求實時、可靠、容錯、支持嵌入式設備、分布式環境、異構平臺。大容量的分布式面向對象實時數據庫，通過提供的類編輯器可以方便地添加、刪除和修改每個對象的屬性、行為和操作命令接口，可以利用面向對象的繼承、重載、封裝等特性擴展數據庫類。分布式實時數據庫以數據庫單元作為最小管理單位，每個數據庫單元可以靈活地在不同計算機間進行遷移和重新部署。

    綜合監控系統開放性在以下方面反映。

3.3.1.1 開放的接口驅動

    綜合監控系統需要與多種外部設備和外部系統實現在各個層面上的互聯互通，因此系統軟件必須保證各部分軟件接口和通信協議的規范性，通過開放的標準協議（如Modbus TCP/IP 、IEC104、OPC、ODBC等）的使用，實現系統與外部設備和外部系統之間的接口，并提供統一的開發模板和應用接口以支持專用通訊接口的接入。

    （1）軟件應可通過開發實現更廣泛的I/O設備支持；

    （2）支持常用的多種接口協議和規范，包括如：OPC、DDE、ActiveX、API、DLL等；

    （3）系統標準通訊接口中包括OPC客戶端，能夠從任何OPC服務器獲取數據；

    （4）系統還應提供標準的OPC服務，可為外部系統提供訪問系統內部數據的OPC服務；

    （5）用戶可以編寫自己的擴展組件并將其嵌入綜合監控系統軟件系統；

    （6）系統支持用C/C++語言為通訊控制器編寫I/O 驅動程序；軟件應支持多種數據庫接口，比如：ODBC、SQL等；

    （7）利用ODBC接口系統可與遵從此標準的異構數據庫互聯，支持ODBC標準的應用程序。

3.3.1.2 數據庫結構開放，易于擴展和增加數據類型

    綜合監控系統監控對象眾多，類型豐富，應采取完全開放的數據庫結構將有利于根據監控對象的特點增加數據庫中管理對象的類型、字段和方法。如果系統軟件采用面向對象設計方法構建一個大容量的分布式面向對象實時數據庫，通過提供的類編輯器可以方便地添加、刪除和修改每個對象的屬性、行為和操作命令接口，可以利用面向對象的繼承、重載、封裝等特性擴展數據庫類。數據庫腳本是這類軟件平臺提供的一種擴展應用功能的手段，既可以用于應用開發階段的行業/專業通用功能的開發上，也可以用于工程階段的定制開發或組態上。數據庫腳本用于描述對象的行為以及對象之間的連鎖邏輯，具有靈活、免編譯的特征。數據庫腳本采用Tcl語言，提供腳本的編輯、執行功能，用于實現以觸發式計算為主的數據處理功能。作為監控系統中重要的實時報警數據，這類系統采用面向對象分析和設計方法構建了多種實時報警類，每個報警類的組成字段可以定義和配置，根據應用需求還可以擴展報警類，從而充分利用對象化設計所帶來的數據庫結構開放的優點。綜合監控系統軟件平臺采用面向對象技術是提升性能的較好選擇。

3.3.2 綜合監控軟件平臺的構架要求

    綜合監控軟件平臺的設計框架采用層次化結構，例如，將系統、應用、工程分為不同軟件層次，各層次相互解耦。具體項目應用中，軟件由平臺包、應用包和工程數據三部分組成：平臺包是一個工業自動化和SCADA系統的通用平臺；應用包是適于城市軌道交通電力、環控、火災報警以及地鐵其他專業的專門應用軟件；工程數據則是本地地鐵綜合監控系統的具體應用數據。應用包針對地鐵行業的被集成子系統應用，針對具體項目完全滿足對系統的每項需求。解耦的軟件平臺可使系統靈活、方便。例如地鐵工程中經常出現的大變更（例如修改站名），軟件只需在工程組態層面修改即可實現。

    軟件的應用平臺主要由系統集成商在長期積累的地鐵綜合監控系統中應用模件組成。目前，軟件技術提倡系統全面采用面向對象的設計思想，包括面向對象的分析與設計、面向對象的軟件開發與實現、面向對象的工程設計與應用，強調知識的積累和重用，通過面向對象方法實現了代碼的重用和工程數據的重用，使系統集成商在地鐵綜合監控系統應用核心技術軟件化、工程化。從而可以順利地在地鐵工程中重用。重用的重點在于對成熟代碼和領域工程知識的重用，即把領域知識和工程經驗轉化為一些程序庫或數據庫，并能通過一定的剪裁手段，產生每個項目適用的“原型”，轉化為本地地鐵工程的應用模件。

    工程組態方面，軟件平臺配置的組態工具簡單易用，業主使用人員在經過短期的培訓后就可以獨立進行數據庫組態、畫面編輯、腳本定義、權限設置、系統維護等操作，有利于業主使用和維護人員在工程實施、調試階段介入相關工作，有利于系統的長期維護和穩定運行。

3.3.3 綜合監控軟件平臺的模塊化要求

    綜合監控軟件系統平臺應采用模塊化設計思想，由配置總控、類編輯器、實例編輯器、圖形編輯器、設備組態工具、命名服務、數據管道、對象數據庫、歷史數據庫、報警事件服務、日志服務、權限服務、人機界面HMI、在線下裝、校時、接口模塊、報表服務等模塊組成，這些模塊通過中間件軟總線（例如，CORBA中間件）實現相互通信，而且可以根據不同模塊的組合實現服務器和工作站的功能需求。這些模塊通過中間件軟總線實現相互通信，而且可以根據不同模塊的組合實現在服務器和工作站的功能需求，這些模塊分為三類：基礎組件，服務組件和應用組件。

    （1）基礎組件

    基礎組件是最底層軟件模塊，包含綜合監控系統軟件的各個部分所使用的基本工具，它們在操作系統之上為所有更高層的系統軟件和應用程序提供了一種統一的開發和運行環境，本質上是一些現成軟件部件COTS。這一層主要有5個組件：

    通用開發工具：是綜合監控系統軟件的開發工具，包括編輯器、編譯器、配置控制工具、語言、調試器、文檔工具等。

    中間件：現成的中間件產品，提供綜合系統軟件子系統和模塊之間通訊的“軟總線”。

                                  圖1   綜合監控系統軟件主要軟件組件

    腳本開發包：現成的腳本開發、運行環境，包括VBS/VBA和Tcl腳本語言，分別用于人機界面腳本系統和對象數據庫腳本系統。

    遠程管理軟件：現成的VNC（Virtual Network Computing，虛擬網絡計算）軟件，提供軟件的遠程部署、管理和控制功能。

    防毒殺毒軟件：用于保護計算機系統免受病毒、木馬、流氓軟件等惡意軟件的侵擾，為綜合監控系統軟件提供無病毒的開發和運行環境。

    CORBA等中間件：現成的中間件產品，提供綜合系統軟件子系統和模塊之間通訊的“軟總線”。

    （2）服務組件

    服務組件層提供以數據中心為核心的、對任何應用程序的開發所必須的基本組件，并完成基本的SCADA軟件功能。

    實時數據庫：用于實時數據的存儲和管理，提供面向（設備）對象特性，實現對象模型的在線管理、分布數據一致和數據庫訪問服務的基本接口。實時數據庫本身提供內部計算功能。

    接口與采集：通過MODBUS TCP/IP、OPC、ODBC、FTP等標準協議實現外部子系統的接入，提供實時、定時、需要時、數據變化傳送等多種采集方式，提供特殊協議擴展開發的軟件框架。

    錯誤系統：包括處理和記錄運行時錯誤的API，定義錯誤條件的工具，以及瀏覽和分析運行時錯誤的工具。

    報警/日志系統：提供系統發生的事件記錄，包括配置工具和應用開發API接口，提供報警和記錄的存儲、管理、檢索等通用服務功能。

    環境管理：實現通訊診斷、任務診斷、冗余切換等運行環境管理功能。

    歷史數據管理：對來自運行時系統的監視數據和事件實現集中長期歷史庫存檔，以及瀏覽、監視和管理存檔數據的工具。

    命令系統：包括命令定義工具，運行時帶命令語法檢查的命令處理器和動態命令調用的應用開發API接口和工具。

    人機界面HMI：包括用戶界面開發的開發工具和控件庫，在線HMI環境。

    應用生成工具：生成標準的二次開發應用程序框架，提供標準化的應用開發流程和模型，提高應用開發質量。

    （3）應用組件

    應用組件層提供專業的綜合監控系統應用功能組件。這個包的主要目標是通過分析綜合監控系統各個專業的典型應用，利用系統軟件提供的工具和開發接口實現專業應用功能，為應用開發提供一個明確的路徑，達到符合固有設計標準的目標和獲得可維護的軟件。

    3.3.4 綜合監控軟件平臺的數據庫要求

    綜合監控系統軟件需要構建一個大容量的分布式實時數據庫，成功的案例是采用面向對象的方法構建面向對象的實時數據庫，它的特點如下：

    1 面向對象特征。對象是系統中在工程設計級所能識別的類的實例，對象不僅表現控制系統中任何物理設備（如斷路器，電機等），也表現邏輯設備（如計算功能塊、方案頁）或高級組合對象（如工藝系統，直流牽引系統、隧道環控系統等）。這里“對象”主要指從用戶視圖中或操作員角度所看到的各種工藝設備，如開關、刀閘、泵、閥門、風機、軌道、電扶梯等，當然也可以包括系統構成設備，如計算機、網絡等。對象數據庫提供的服務有：

    （1）支持面向對象持久性服務，支持重要的面向對象特征，如封裝、對象標識、對象關系、繼承和多態；

    （2）基本數據庫操作如基本的數值讀寫定位服務，支持對象創建、修改和刪除的基本操作；

    （3）通用的數據查詢和獲取接口和對象暴露的操作接口；

    （4）多對象行為，支持多對象復合行為；

    （5）訂閱基本的點值改變的服務。

    2 分布特征。在工作站或服務器使用的每個本地數據庫可以只是全局數據庫的部分映像。這些數據是工作站或服務器自己的真實狀態，或出于性能原因只是在本地維護的一個副本或映像，這樣就無須每次都通過網絡訪問數據。整個數據庫是所有這些邏輯片段的合并。面向對象的數據庫具有很好的擴展性和適應性，它能滿足數據規模的持續擴充以及應用軟件的修訂。

    3 事件驅動特征。在對象數據庫中，對象的行為將可實現應用功能。實時數據庫能處理20~50萬個數據點，應用功能的執行將主要采用事件驅動方式。事件源主要是外部變量的狀態變化，例如，系統探測到外部變量的值變化，產生一個例外報告事件，該事件被主動傳遞給相關對象，觸發對象的相關動作，完成一定的系統功能，如報警判斷、聯動或歷史數據收集和分析。事件觸發為從下往上逐層觸發的方式，如該對象還有父對象，則將本層處理結果也以例外報告事件繼續上報，直到頂層對象，這是一個從下至上的串激過程。面向對象的實時數據庫支持了綜合監控系統所要求的事件驅動能力。

    實時數據庫采用事件驅動的方式工作，可以定義設備與子設備、不同設置間的關聯關系，還支持部署在不同計算機上的設備間的關聯。強大的事件驅動模型有利于實現各種聯動功能。

    4 內存數據庫特征。考慮到系統運行時的實時性要求，數據庫將主要實現為內存數據庫，但也允許少量的非實時性信息駐留硬盤，內存數據庫中只保留這些文件的連接。實時數據庫提供多個屬性，它的讀寫性能明顯優于關系數據庫的性能。數據庫以ASCII或二進制格式保存，二進制格式允許快速保存。

    綜合監控系統的對象建模相應分為通用SCADA系統對象模型、地鐵各專業對象模型和具體工程對象模型，在系統軟件內核支持下，建立數據庫基本模型。圍繞此模型，建立一個類編輯器工具、一個程序生成器工具、一個對象模板編輯器、一個實例（對象）編輯器，即數據庫組態工具。通過這些對象數據庫定義和擴展開發工具，能有效支撐系統監控設備對象的擴展。

3.3.5 綜合監控軟件平臺的安全性要求

    系統軟件支持完善的安全部署模式，安全機制作為對象固有的行為直接定義在對象內部，提供對象級的訪問權限控制，支持只讀、配置、一般寫、確認寫、自由訪問、采集禁止、報警確認等多種數據安全訪問機制，而且在應用開發階段，針對各個專業的典型應用還支持專業化的安全訪問操作，如設備掛牌、權限移交等。

    更多內容：

    地鐵綜合監控系統建設的關鍵問題分析（一）——建設綜合監控系統的第一關鍵點
    地鐵綜合監控系統建設的關鍵問題分析（二）—— 地鐵綜合監控系統技術內涵分析
    地鐵綜合監控系統建設的關鍵問題分析（四）——地鐵綜合監控系統軟件分析
    地鐵綜合監控系統建設的關鍵問題分析（五）——軟件國產化的問題
    地鐵綜合監控系統建設的關鍵問題分析（六）——綜合監控系統設計中的問題
    地鐵綜合監控系統建設的關鍵問題分析（七）——綜合監控系統實施風險分析
    地鐵綜合監控系統建設的關鍵問題分析（八）——綜合監控系統的其他問題