以行車指揮為核心的綜合監控系統軟件集成方案研究

謝紅兵，劉小樹，智艷利（北京和利時系統工程有限公司，北京 100176）

以行車指揮為核心的綜合監控系統軟件集成方案研究

謝紅兵，劉小樹，智艷利（北京和利時系統工程有限公司，北京 100176）

1　引言

城市軌道交通綜合監控系統ISCS（Intergrated Supervisory Control System）是通過建立一套統一的軟硬件網絡平臺，對地鐵機電設備系統進行協調、管理、監督和控制。ISCS將各自獨立的機電設備控制系統通過網絡有機地聯結在一起，目的是由ISCS監控和協調各相關子系統設備的工作，充分發揮各種機電設備的效率，降低地鐵運營成本，提高設備管理水平，節約資源（人力和物力資源），并為OCC控制中心和乘客提供一個便利快捷舒適的工作環境和乘車環境以及在災害發出的情況下最大限度地保護人的生命和財產安全。目前國內的綜合自動化普遍采用的是以電調、環調為核心的綜合監控系統方案，即綜合監控系統與信號系統中的ATS（自動列車監督）子系統互聯，進行信息交換。這種方案沒有將地鐵運行中最重要的環節“行車調度指揮”真正集成，使得綜合自動化系統最重要的系統聯動功能難以充分發揮作用。[1]

以行車調度為中心的綜合監控系統這一課題在國內已經開展了幾年的研究，并有不少論文發表，比如文獻[2]研究了綜合監控系統集成ATS的優缺點及可行性，得出綜合監控系統集成ATS具有一定的實施基礎并可大幅度提升運營管理效率的結論；文獻[3]則給出了戴帽、內嵌和完全集成3種實施方案，并在集成系統的接口范圍、接口劃分和功能設置上都給出了具體的方案；而南瑞和卡斯科已經在北京地鐵6號線實現了一個集成后的系統，并取得了不錯的效果。但是，以上的研究和實施更偏重于認為傳統綜合監控系統與信號系統是兩個廠家提供的兩套系統，強調接口分開，這就使最終系統的集成度取決于兩家軟件的開放程度，因此是一種“有縫”的集成。這對于以后系統功能的擴展，特別基于聯動的列車事故管理功能的逐步增加是不利的。比如新的功能可能要求雙方的接口都要修改，協調起來比較困難。

本文通過對傳統綜合監控系統和ATS系統的軟件特點和功能分析，從軟件體系結構的角度提出一種基于OPC基金會發布的最新國際標準OPC UA的“無縫”集成解決方案，期望能有助于解決上述問題。

2　功能分析

2.1傳統綜合監控系統

傳統以電、環為核心的綜合監控系統通常是一個地理分散分層分布式系統，通過功能集成和技術集成將地鐵日常運營和輔助運營的各個自動化子系統集成在一起，實現集中化和一體化協調運作。其主要特征是統一的人機界面（HMI）和統一的體系結構。綜合監控系統的核心是一個運行在通用硬件平臺上的SCADA軟件，該軟件通常具有基于中間件和組件結構的客戶/服務器體系，分布式面向對象編程結構，高效的、支持層次化對象的實時數據庫、事件驅動和周期調度的計算引擎，可插拔的接口I/O驅動（以接入外部子系統），全套的實時、歷史數據和事件的管理等，還融合了大量COTS軟件，比如關系數據庫。此外，還要包括一組支持擴展的API，這是SCADA軟件能成為綜合監控軟件平臺的一個基本條件。其功能主要包括數據采集、遠程控制、報警管理、歷史趨勢和統計、報表生成、二次計算、運營記錄和事故回放等。

傳統綜合監控系統所集成的自動化專業的共同特點大都是基于測點的。但是在監控特點上，實際被集成或互聯的不同專業子系統并不完全相同，比如電力專業，其三級監視（變電所、車站和控制中心）、二級控制（中心、變電所）是比較典型的SCADA監控方式，強調正常運營時的全局性協調和事故情況下的本地直接控制；而面向車站和區間機電設備監控的環控（BAS）專業，其在控制中心更像是采用了一種所謂的Observer（觀察者）模式，其主要的控制點在車站一級；而互聯的某些子系統，比如AFC，則呈現一種“反向”的Observer模式，即中心作為數據接入點，車站作為觀察者。以上這些均要求SCADA軟件平臺能夠通過適當的配置和部署自動適應。

因此，作為綜合監控系統核心的SCADA軟件，往往強調的是它的通用性和開放性。

2.2ATS（列車自動監督）

ATS系統傳統上屬于信號系統，位于整個ATC系統的最上層，是地鐵信號系統的指揮中樞，是集自動監控、信息管理和綜合決策為一體的綜合系統。主要實現對列車運行及道岔、信號等設備狀態的監督與控制，給行車調度人員顯示出全線列車的運行狀態，監督和記錄運行圖的執行情況，在列車因故偏離運行圖時及時做出調整，按照計劃自動完成對全線列車運行的管理。在系統故障或其他特殊情形下，使調度員可通過ATS人機界面進行人工干預等。其典型功能包括列車追蹤和識別、自動調度、自排進路、自動列車調整和控制請求確認。此外還包括一些常規的監視系統功能如報警處理、歷史記錄等。在系統體系結構上，根據信號系統廠家的不同，大體上有集中式、分散自律式和分層分布式幾種。

相比于以電、環為核心的綜合監控系統，ATS系統有以下幾個特點：

（1）ATS是特定的業務系統，強調的是專用性而不是通用性；

（2）ATS有自動控制功能，例如自排進路、自動調整等，自動命令與底層列控系統構成控制回路，這與綜合監控其他專業偏重人工或半自動的開環控制有所不同；

（3）ATS屬于安全相關系統，如文獻[4]中列出的中途停車、取消臨時限速、解除區間封鎖或施工區等可能潛在地導致系統危害的操作，故其安全完整性等級是SIL2級。此外，從系統集成國際標準IEC62264（GBT20720）《企業控制系統集成》的分層模型角度看，ATS并非同綜合監控系統其它典型專業那樣完全屬于面向過程的控制系統，而是有相當一部分功能類似于制造業工廠中的MES系統，典型就是運行圖相關功能，包括編制、執行、執行過程監控、計劃調整和實績的統計，以及設備的維修等，唯一不同的是制造業中圍繞的是生產計劃，而軌道交通圍繞的是運輸計劃。這就表明ATS系統本身不是鐵板一塊，而是可以拆分的。

3　建議的解決方案

3.1功能分布

根據前面的分析，我們提出的解決方案是將目前地鐵多數信號標中要求的ATS系統功能拆分為兩部分：基本監控和行車指揮，基本監控包括對列車和信號設備（道岔、軌道區段、站臺設備、信號等）的監視和人工控制（道岔、進路控制等），這部分由綜合監控的SCADA軟件平臺實現。而行車指揮部分則作為監控軟件平臺之上的應用程序，通過讀寫綜合監控數據平臺中的數據，實現ATS的列車跟蹤、自動控制和自動調整功能。ATS部分的功能運行中，實時數據取自綜合監控系統數據平臺，靜態或實時數據（如軌道數據、運行圖數據等）仍取自關系數據庫。集成后的系統使用原來綜合監控系統提供的統一風格的HMI，由SCADA平臺實現站場圖列車跟蹤顯示，ATS系統專用對話（如運行圖等）以控件形式嵌入到該HMI中。示意圖如圖1所示：

圖 1 ATS應用程序與綜合監控平臺的關系

本方案中，綜合監控的通用SCADA軟件平臺直接與底層信號系統中的ATP、CBI、VOBC等接口，實際截斷了原來ATS與底層信號系統之間的數據傳輸通道，并起到一種底層信號系統的代理作用。它向ATS應用軟件提供實時的、原始的信號設備狀態，所有ATS產生的命令，都經由綜合監控系統的實時服務器和前端機（FEP）輸出，使得ATS能夠控制相關的現場設備。

融合了ATS基本監控能力的綜合監控軟件平臺與原來相比，需要增加一個至為重要的功能，即人工控制命令與自動控制命令互鎖，適用于任何列車和信號系統設備以確保：

? 受ATS基本監控影響的所有操作員請求控制的優先級都比ATS應用程序的自動命令優先級高；

? 所有操作員控制請求都被直接發送給現場，并遮蔽ATS應用程序產生的現場命令；

? 所有ATS應用程序產生的命令都不能遮蔽操作員命令。

例如，對ATS應用程序建立的進路請求，有權限的操作員可以取消該進路并請求設置另一條進路，并且后一條人工建立的進路不能被自動進路所取消。

3.2數據存儲

本方案中，ATS應用程序與自含的行車調度所需的靜態數據和運營數據一起工作，大體包括：物理軌道拓撲（防護范圍內的車站、站臺、停車點信息、道岔信息、坡度、限速、線路長度、上下行股道信息、信號機及左右線路等）、運營網絡（正常運行交路、降級運營交路、調整規則）、進路表、運行時刻表、發車列表等。

綜合監控數據平臺則包含所有來自現場的信息（道岔、軌道占用、站臺占用、信號等）以及HMI站場圖列車移動動畫所需要的由ATS處理后的信息（如列車識別號、邏輯區段的占壓等）。

3.3數據交互

ATS應用程序通過訪問綜合監控數據平臺獲得如下信息：

? 物理軌道占壓狀態；

? 進路情況；

? 道岔狀態；

? 信號情況等。

ATS應用程序將處理過的如下信息寫入綜合監控數據平臺的實時數據庫中，或穿過綜合監控數據平臺的提供人工/自動命令互鎖機制輸出到底層信號系統。

? ATS占壓狀態；

? 軌道上的列車數量；

? 進路排列命令；

? 區間列車速度命令；

? 站臺停靠時間命令。

ATS應用程序周期讀出（例如每秒）綜合監控數據平臺中相關監控設備的狀態，執行運輸管理的處理（列車跟蹤、車站發車管理、列車進路的選定及在線調整等）以及寫入動畫顯示所必需的結果；ATS周期性（例如每10秒）監督旅行信息的顯示并核查列車到站，以便修改預報時間。

4　軟件體系結構

4.1中間件服務總線

與其它類型的分布式應用程序一樣，現代SCADA軟件也廣泛采用基于中間件和基礎件的面向組件的軟件架構方法。這種方法是將以前的客戶端/服務器兩層結構擴展為三層，把業務邏輯的處理抽象成一個個基礎組件，然后把這些組件用一個中間層組件（中間件）進行協調，由中間件負責各個組件所需要的事務和安全等公共基礎服務以及組件的管理和監控等，這就使中間件成為一條類似硬件總線的軟件總線。基于軟件總線，任何應用程序或軟件系統就能方便地集成到以該中間件為核心的系統中，在“軟件總線”之上實現“即插即用”。軟件總線機制使得基于中間件開發的系統具有良好的可擴展性，使得系統結構的差異對應用層透明。

在選定了一種中間件技術之后，所有的軟件組件都在這個選定的中間件平臺上面搭建。曾經流行的中間件平臺包括：SUN公司主導的J2EE平臺，微軟主導的COM/DCOM平臺以及OMG主導的CORBA平臺。目前在地鐵綜合監控系統的SCADA軟件平臺中運用比較廣泛的是CORBA和DCOM。一個典型的ISCS軟件包的體系結構如圖2所示。

圖 2 一種ISCS軟件體系結構

基于這種中間件技術的接口技術具有3個特點：（1）通信方式以同步調用方式為主；（2）網絡環境以局域網為主；（3）集成層面以數據層和方法層為主。位于某個安全邊界之內的單條線路的綜合監控系統采用這樣的軟件總線還是比較合適的，這也是目前國內地鐵綜合監控系統的主流。

但是從未來發展趨勢看，綜合監控系統必然在垂直方向和水平方向參與更大范圍的系統集成。水平方向上，目前在路網層面考慮問題比較少，對于路網線路間的災害信息互傳及聯動控制配合的接口方案普遍沒有進行深入研究，比如換乘站發生災害時，對相關各線均有影響，須各條線路共同管理。從地鐵運營角度看，要求整個車站的防災設備統一調度，這就需要不同線路的綜合監控系統之間的集成互操作。垂直方向上，綜合監控系統也需要向信息化層面擴展。

因此，我們認為目前采用的基于現有的中間件平臺的開發的產品還是存在一些弊端。

（1）耦合度過高。客戶端和服務器必須是相同的中間件平臺，雙方使用相同的接口IDL，IDL定義的任何改變都會引起互聯雙方的軟件重新編譯，并且這中間沒有一種中間件技術可以完全蓋過其它技術。不同廠家的軟件產品在集成時可能會因選擇的技術平臺不同而形成新的“信息孤島”。

（2）安全性困難。一個系統的安全性是指其可以免受非授權訪問和操作的特性，具體包括身份認證、授權、保密性、數據完整性等。上述中間件平臺也都提供了相應的安全機制，例如CORBA的安全服務，但都不是固有的，并且設置起來比較困難。

（3）防火墻不友好。上述中間件平臺普遍采用通訊端口動態分配，比如基于DCOM的OPC客戶端首先通過TCP 135端口向OPC 服務器發送連接請求，由OPC服務器動態分配一個1024~65536之間的動態端口號返回給OPC客戶端，然后OPC客戶端再通過這個動態端口向OPC服務器發送數據請求，并獲得對應的控制數據。因此如果防火墻隔開了客戶端和服務器，因端口不固定，通訊就難以完成。

（4）除非采用傳統OPC，否則接口定義沒有統一的標準。其接口的應用層語義是廠家各自規定的，所以并不穩定，導致無法適應不斷變化或增長的應用軟件需求。

因此分布式應用之間的互通互操作問題依舊存在。為避免上述問題，建議方案是采用的國際標準OPC UA來取代上述中間件作為綜合監控系統平臺的軟件總線，使該平臺成為具有安全性、可擴展性、實時性、支持事件聚合和過濾的SOA（面向服務體系結構）的系統，并能融合基于掃描和事件驅動的子系統。

4.2OPC UA功能特征

OPC UA是OPC基金會提出的一個較新的規范，并已由IEC62541[5]標準化，用于工業系統中應用之間的數據交換，基于Web服務的概念。OPC UA的設計目標之一是使用標準的網絡基礎設施訪問大量實時數據，同時保持足夠高的性能。OPC UA指定了一個客戶機/服務器模型進行信息交換，客戶端可以訪問、讀取和修改的服務器的地址空間。該規范為服務器上的信息表示定義了對象模型，以及一個預定義的服務集，用于瀏覽、查詢、創建和操縱地址空間中的對象。信息是用OPC UA和供應商定義的數據類型、編碼和傳輸映射來通訊的。目前OPC UA被普遍認為是互聯網時代的工業控制標準協議。

OPC UA在幾個重要方面擴展了先前的傳統OPC工業標準，如平臺獨立、可伸縮性、高可用性和互聯網能力。其以下重要技術特征可以為綜合監控系統的通訊骨架和軟件的互操作帶來諸多好處。

（1）平臺中立。通訊技術獨立于廠商、行業、操作系統和編程語言。對主流的操作系統和編程語言都有相應的協議棧版本。OPC基金會為它的成員提供了以3種不同的編程語言編寫的通信協議棧形式的實現——ANSI C、C＃和Java 。而協議棧是由OPC基金會維護的，這樣可以確保采用OPC UA的不同產品之間能互聯互通。

（2）面向服務的架構。OPC UA定義了一組粗粒度的通用服務，對于不同的功能（讀/寫/發信號/執行、導航/搜索、連接/會話/安全），OPC UA定義了不同的服務集。這些服務集完全覆蓋和擴展了傳統的OPC DA、A&E和HDA的功能，并已經標準化，因此相互是兼容和可互操作的，無須調用者對某個特定的服務的結構和行為有專門的了解，也不需要像經典Web Service那樣定義WDSL。

（3）可穿越防火墻。OPC UA采用了一種基于TCP的、優化了的二進制協議，只在4840端口進行數據交換，該端口已在IANA（The Internet Assigned Numbers Authority，互聯網數字分配機構）中注冊，因此在防火墻中只需要開辟這一個端口。與信息系統互聯時，也可以選擇支持Web Service和HTTP。集成的加密機制可確保在互聯網上的安全通訊。

（4）固有的安全性。OPC UA的安全模型完全把其適用場景定位在一個開放的網絡環境下，因此采用了成熟的安全理念，包括用戶身份驗證、消息簽名和傳輸用戶數據的加密等選項。技術上采用基于安全的互聯網通信已經證明了的標準，如SSL、TLS和AES等標準，使用X509證書、Kerberos或用戶/口令字方式進行應用程序的認證，以確保防止未經授權的訪問或過程數據的破壞，以及因操作不慎所產生的錯誤。并且安全機制是標準的一部分，對廠商是強制性的。用戶可以按照自己的使用情況并入各種安全功能。此外還提供安全審計功能。

（5）高可用性。OPC UA定義了一個健壯的體系結構，具有可靠的通信機制、可配置的超時和自動錯誤檢測和恢復機制。OPC UA客戶端和服務器之間的通信連接可以被監控。OPC UA還提供了可應用于服務器和客戶端應用程序的冗余功能，以防止數據丟失，從而實現最大正常運行時間的高可用性系統。

（6）可伸縮性。OPC UA可以在不同方向上控制規模，伸縮幅度相當大，既可以在硬件資源有限的嵌入式設備，也可以在非常強大的主機上應用。目前既有實現在芯片級的用例，也有實現在Amazon云中的項目。

（7）支持信息建模。OPC UA定義了基于“節點”和“引用”的抽象數據模型，服務器可以在它的地址空間中暴露某種類型的訪問節點的實例。該地址空間可以按層次化或非層次化方式組織節點，并由引用相互連接形成一個完整的網狀網絡。 使用OPC UA通訊的廠家或其他標準化組織可以基于該數據模型定義和擴展自己的信息模型，形成自定義類型。客戶端可以在權限許可的情況下僅通過不變的標準服務沿著某種引用發現或瀏覽服務器中存放監控對象的實例和類型系統。目前如IEC、EDDL、PLCOpen、ISA95等國際標準化組織均依據OPC UA發布了定義本應用領域信息模型的配套規范。

（8）發現機制。OPC UA定義了不同的“發現”機制，可以通知到所有具有OPC UA能力的設備及其在子網內的功能/特性。因此，掛接在這條軟件總線上的組件和業已提供的功能（服務）之間的通訊是自組織的，可以“即插即用”地參與到“智能”的、網絡化的組件編排/組合中。

4.3OPC UA的運用

本節提出的以行車指揮為核心的綜合監控系統建議方案和上面介紹的OPC UA的功能特征進行分析，以說明給出的軟件體系結構的適用性。

4.3.1SOA架構

采用這種架構潛在的含義是采用面向消息和異步通訊，服務在形式上被界定為服務提供者和消費者之間的消息交換。這就比一般中間件技術偏重于同步執行的遠程過程調用（RPC）有更大的可伸縮性，可以避免數據訪問時某個耗時長的事務阻塞客戶端其他任務的執行，從而可以支持更多的客戶端。同時OPC UA還支持服務等級和負載平衡的概念，這一點非常有利于綜合監控系統的數據平臺未來向IT層開放，以及支持當前數目不定的復示工作站的需求，通過工程配置可以在這些數據訪問需求和面向過程的操作員工作站之間取得性能的平衡。

4.3.2安全性

ATS原本屬于信號系統中的一個子系統，一般認為其應處于一個封閉的網絡環境內，但是，當采用完全集成方案與綜合監控系統進行軟硬件一體化后，這一前提是否還能成立？從綜合監控系統發展趨勢看，通過深度集成無線通信系統，有可能實現現有綜合監控系統的可移動化和遠程服務能力，從而改變以往系統只能在車站和中心調度室固定終端上操作和使用的缺點。針對地鐵維修人員提供移動維修功能，針對地鐵火災等緊急情況下提供應急預案管理、指揮和決策輔助功能等[6]。這一趨勢對以行車指揮為核心的綜合監控系統同樣適用。因此，此時必須按照開放網絡環境來考慮，即最終的系統應按照EN50159-2而不是EN50159-1的環境要求來進行安全認證。這其中的主要區別就在于開放網絡環境中，“具有未知、可變或非受信屬性且數量未知的參與者”可能對安全相關系統帶來的信息安全風險。對此，我們認為OPC UA提供的安全機制可以給予足夠的防護，因為OPC UA是在開放的企業內聯網和互聯網的場景下建立的安全模型。目前OPC UA在同樣高安全完整性等級的核電站上已有應用。

4.3.3高可用性

與一般WebSeverice的“無狀態”模型不同的是，OPC UA要求一個“有狀態”模型作為增強通訊健壯性的一個特征。狀態信息被保存在應用程序的會話內。狀態信息的一個例子是訂閱，用戶憑證和延續點可以在操作上跨越多個請求。 OPC UA通信遵循客戶-服務器模式，客戶端發送一個異步服務請求，并從服務器接收響應。每一個服務調用包含一個可配置的超時時間，客戶端將等待直到響應到達。這確保了一個高度響應性系統。序列號用于識別對應的請求/響應消息配對。當訂閱事件或值變化通知時，每個發布的數據響應由客戶端用下一個發布請求進行確認。萬一連接中斷或傳送失敗，服務器保留未確認的消息，并在連接再次恢復時重新發送他們。在此期間收集的數據將被服務器緩沖或排隊，使得在短暫的網絡中斷不丟失任何數據。OPC UA保證可靠的數據傳輸而不丟失數據，即使是在不可靠的傳輸媒介上。這種機制可以有效防御EN50159-2之附錄D[7]中列出的大多數如下基本消息錯誤：消息重復、刪除、插入、重排序、損毀、延遲和偽裝（除延遲外）。由于建議的以行車指揮為核心的綜合監控系統方案將原來ATS中的基本信號監控功能轉移到綜合監控軟件平臺，因此相應的通訊環節的RAMS要求需要基礎平臺來承擔。

4.3.4支持信息建模

OPC UA不僅是一個通訊協議，同時也提供了一套信息建模的規范，從而使系統集成更具“智能性”。如果地鐵綜合監控所集成的大量子系統都能統一到此規范（盡管目前還不現實），則可大大縮短工程實施階段的設計聯絡和接口談判時間，從而縮短建設周期。作為客戶端的集成系統只需要持有被集成系統的授權證書，即可訪問被集成系統數據庫中的所有數據類型，并瀏覽所有的監控對象實例，根據自己的監控或查詢要求選擇，而無需集成系統的廠家再提供如測點清單之類的文檔。

支持信息建模的另一個好處是對緊密集成的互操作軟件，如本文所涉及的綜合監控系統平臺軟件與ATS軟件的集成的用例，接口更加清晰和標準。如前所述，綜合監控系統平臺軟件強調的是它的通用性，其本質上仍屬于一種通用的組態軟件，而這種“通用性”更多指的是面向測點的工控系統，其所監控的對象狀態最終會落在如模擬量、開關量上。而ATS并非典型的工控系統，其核心數據結構與常規的工控系統并不完全相同。例如一個軌道區段（計軸區段）可能會表示成如下的一個復雜數據結構：

該區段對象的每個狀態元素都不構成典型的模擬量、開關量。運用OPC UA擴展性和信息建模，就可以解決這一問題，使得該軌道區段對象在保持原有信息結構的前提下，能夠存入具有OPC UA地址空間格局的綜合監控數據平臺的實時數據庫中，還能用通用的服務接口訪問。方法是綜合監控系統平臺軟件可以按照“抽象工廠”設計模式為應用程序（這里是ATS），提供一個“工廠”模板，該“工廠”的職能是將具有一定復雜數據結果的監控對象定義加載到綜合監控數據平臺的實時數據庫中。而作為ATS一方，仍可保留其原有的數據配置工具（比如站場圖編輯器）和工作方式，只需要實現基于該“工廠”模板編寫一個具體的“工廠”，按照OPC UA規范的地址空間數據模型的要求把站場圖編輯器產生的、有必要存入實時數據庫的數據結構和實例加載到同樣符合OPC UA地址空間要求的實時數據庫中即可。這樣ATS軟件就可以在運行時通過標準服務訪問具有自己設計并熟悉的數據結構的實時信息。圖1中的“聯動應用程序”也類似。

4.3.5發現機制

目前國內地鐵建設的一大特點是一條線路分期施工、分批開通，發現機制很適合這種系統不斷“生長”的過程。新開通車站的綜合監控系統所涉及的服務器可以自然地融入已投運的那部分車站的系統，而沒有硬性的如工程重構、倒切等人工干預過程，最終規模不斷擴展的服務器集群形成整個系統的服務云。

5　結語

本文從功能分析出發，探討了以行車指揮為核心的綜合監控系統軟件的集成方案，給出了一個建議的體系結構，并對該結構所涉及的關鍵技術OPC UA在城市軌道交通自動化乃至信息化體系中的作用和應用前景進行了分析。我們的判斷是，集成與開放是未來必然的發展趨勢，因此以開放的、成熟的商用化和標準化技術取代專有技術應成為新一代城市軌道交通自動化系統的基本設計理念。

[1] 周庭梁, 孫軍峰, 孫春榮. 談以行車指揮為核心的城軌交通綜合監控系統[J]. 現代城市軌道交通, 2009, (3).

[2] 郭永泉. 城市軌道交通綜合監控系統集成信號ATS的研究[J].現代城市軌道交通, 2008, (6).

[3] 魏祥斌. 集成信號列車自動監控子系統的綜合監控系統方案[J]. 現代城市軌道交通, 2012, (8).

[4] IEEE Std 1474.1-1999 IEEE Standard for Communications-Based Train Control(CBTC) Performance and Functional Requirements[S].

[5] International Electrotechnical Commission: 62541-1 Ed. 1.0: OPC Unified Architecture Specification -Part 1: Overview and Concepts. IEC Std, 2008[S].

[6] 李天輝.城市軌道交通綜合監控系統的技術發展[J]. 自動化博覽, 2013, (10).

[7] EN50159-2: 2001 Railway applications-Communication, signalling and processing systems -Part 2: Safety related communication in open transmission systems[S].

Integration Solutions Research for Urban Rail Transit Integrated Supervisory Control System with Traffic Control as the Core

本文從功能分析出發，研究了以行車指揮為核心的綜合監控系統的軟件集成方案，給出了一個建議的軟件體系結構，并對該結構所涉及的關鍵技術OPC UA在城市軌道交通自動化乃至信息化體系中的作用和應用前景進行了分析。

綜合監控系統；信號系統；ATS；OPC UA

Based on the functional analysis this paper introduces the the software integration solutions for Urban Rail Transit Integrated supervisory control system with traffic control as the core. One kind of software architecture is also recommended. The key technology OPC UA related to this architecture in urban rail transit automation and its application prospects are analyzed.

Integrated supervisory control system (ISCS); Signal system; Automatic train supervision (ATS); OPC Unified Architecture (OPC UA)

B 文章編號：1003-0492(2015)01-0090-06 中圖分類號：TP273

謝紅兵（1962- ）男，江蘇南京人，研究員級高級工程師，本科，現就職于北京和利時系統工程有限公司，主要研究方向為分布式控制系統及其應用。

劉小樹（1982- ）男，江西吉安人，工程師，碩士，現就職于北京和利時系統工程有限公司，主要研究方向為城市軌道交通綜合監控。

智艷利（1982- ）女，河南鄭州人，工程師，碩士，現就職于北京和利時系統工程有限公司，主要研究方向為城市軌道交通綜合監控。