摘  要： 探討了在城市軌道交通綜合自動化系統中將傳統以電調、環調為核心的綜合監控系統與信號系統中ATS系統集成后在開放網絡環境下的安全性問題，識別了關注的重點，給出了一個基于OPC UA的具體實現方案。最后給出了若干實施建議。

　　關鍵詞： 綜合監控系統；信號系統；ATS；開放網絡環境；安全性；可靠性；OPC UA

0 引言

　　目前國內的城市軌道交通綜合自動化普遍采用的是以電調、環調為核心的綜合監控系統方案，即綜合監控系統與信號系統中的ATS（自動列車監督）子系統互聯，進行信息交換。這種方案沒有將地鐵運行中最重要的環節“行車調度指揮”真正集成，使得綜合自動化系統最重要的系統聯動功能難以充分發揮其作用[1]。要提升綜合監控系統的運營維護管理水平，提高集成度，形成以行車調度指揮為核心的綜合監控系統是必由之路。

　　以行車調度指揮為核心的綜合監控系統的顯著特征是集成信號系統的ATS子系統，同時集成與行車指揮有關的系統，從而實現對軌道交通中環境、供電、設備、乘客、列車的全面監控，同時通過緊密集成后形成的大范圍信息共享，可以進一步實現各個專業子系統之間的快速聯動，真正做到為運營指揮部門服務，提高軌道交通運營指揮的自動化水平[2]。

　　實施這樣一個以行車調度指揮為核心的綜合監控系統將會面臨兩個挑戰。

　　第一個挑戰是采用何種集成技術方案。這是因為傳統的綜合監控系統和信號系統是由不同的廠家提供的。對此參考文獻[3]給出了戴帽、內嵌和完全集成3種實施方案，并在集成系統的接口范圍、接口劃分和功能設置上都給出了較為具體的方案；參考文獻[2]則給出了一個分階段實施方案，但大體思路與參考文獻[3]類似；而南瑞和卡斯科已經在北京地鐵6號線實現了一個接近完全集成后的系統，并取得了不錯的效果。集成技術方案的主要難點一般聚焦于兩點，一是如何協調和分配安全完整性等級，二是傳統綜合監控系統和ATS系統軟件在多大程度上向對方開放。

　　第二個挑戰就是信息安全（Security）。因為無論傳統的綜合監控系統還是ATS系統目前都是運行在一個封閉的網絡之內，對外沒有互聯互通。由于沒有現實的信息安全威脅，系統在設計、實現與部署過程中，其主要指標是可用性、功能、性能、功能安全（Safety）、實時性等，而無需過多考慮網絡攻擊、信息安全等問題。但是，隨著近年來以數字化、網絡化和集成化為特征的ICT（信息和通信技術）的快速發展，互聯網、云計算等應用的日益普及，綜合監控系統不能不考慮進一步對其安全邊界之外的用戶開放，無論是路網內各條線路之間水平方向的信息交換，還是作為基礎信息平臺在垂直方向向信息系統擴展，趨勢都是與線網內外的其他系統互聯互通，特別是當以行車調度指揮為核心的綜合監控系統逐步形成線路內唯一的集成信息共享平臺后，這一趨勢看上去更加明顯。

　　因此，新一代的以行車調度為中心的綜合監控系統在集成方案和技術平臺的選擇上都應該在開放的網絡環境下考慮，并將保障信息安全作為一項關鍵的設計原則。

1 目標環境下的系統風險

　　1.1 安全性和可靠性

　　對于城市軌道交通系統，安全性指在系統運營過程中，保障“乘客和員工不受傷害以及設備（設施）不遭破壞”的能力。保障“乘客和員工不受傷害以及設備（設施） 不遭破壞”的能力包含了兩個方面，即不發生意外的安全（Safety） 和免遭破壞的安全（Security）[4]。為劃清這兩個術語之間的區別，本文以下將“Safety”稱為“功能安全”，將“Security”稱為“信息技術安全”。

　　根據ISO8402 的定義， 功能安全是“使傷害或損害的風險限制在可接受的水平內”。系統的安全性視為是其一種內在的特性， 這種屬性確定了系統在運行中， 避免觸發人身傷亡、重大財產損失或環境污染等事故的能力。功能安全由安全完整性來度量。根據IEC61508中的基本定義，安全完整性是指在規定的條件下、規定的時間內，安全系統成功實現所要求的安全功能的概率[5]。

　　而信息技術安全是指自動化系統本身也需要加以保護，以防止濫用、安全攻擊、未經授權的訪問和泄密等，保護數據和服務系統。信息技術安全措施的目標是提高保密性（特定的機器/人類用戶的數據和服務的訪問限制）、完整性（數據的精度/完整以及服務的正確操作）和可用性（測量系統在特定時間內執行功能的能力）[6]。

　　在軌道交通領域普遍采用的基于IEC61508的歐標EN51026中沒有規定確保系統信息技術安全的要求，但將其作為表征鐵路系統應對破壞行為和人們不合理行為自我恢復能力的一個要素[7]，因此是系統危害分析中的一個重要方面。從根本上說，信息技術安全性是為降低攻擊所造成的損害。通過識別對系統的威脅，以及識別系統對這些威脅的漏洞，并提供相應的對策，以直接減少漏洞、抵消威脅，或從成功的攻擊中恢復。通過多年來通用的信息系統安全性的經驗，已經形成了一組相當穩定的安全目標，并形成一系列相關的標準。像地鐵綜合監控系統這類工業自動化系統要達到安全性也必須滿足這樣一組目標，這些目標主要聚焦在可用性、完整性、保密性、認證、授權和不可抵賴性幾個方面（按重要性排列）。不可抵賴性主要體現在事后審計上，因此一般來說重要性最低。而對工業自動化系統設備的可用性、實時性、可控性等特性要求很高，因此可用性最為重要。

　　與安全性有區別但又有密切關系的是可靠性。可靠性是指既定環境下既定時間內一個（技術）系統正常運行的概率。依賴于所提供系統或由該系統本身的正確操作，包括低故障率、高容錯性（即能夠保持正常運行，即使發生故障時）和魯棒性（基本功能的能力，以保證不發生故障）[6]。對于城市軌道交通系統，可靠性指在系統運營過程中，保障“乘客準時到達目的地”的能力。通常所講的“保障乘客安全正點旅行”即包含了系統安全性與可靠性兩方面的概念。

　　1.2 開放網絡系統

　　開放網絡系統按照歐標 EN50159的定義，是指“具有未知、可變或非受信屬性且擁有未知數量的參與者，用于未知電信服務并對未經授權的訪問進行評估的系統” [8]。顯然與封閉傳輸系統相比，這諸多“未知”因素增加的安全風險主要來自信息技術安全方面。按照EN50159的安全相關系統在通信上的防護要求，主要體現在防御傳輸錯誤和防御未經授權的訪問上。實際上還應該加上可用性，因為惡意的網絡攻擊（比如消息洪水）可能造成某臺功能服務器性能顯著下降，從而使安全相關功能受損或不可用。

　　1.3 安全相關系統

　　傳統上ATS雖然不是故障安全系統，但仍具有安全相關功能，如參考文獻[9]中列出的中途停車、取消臨時限速、解除區間封鎖或施工區等可能潛在地導致系統危害的操作，故其安全完整性等級是SIL2級。并且，與傳統綜合監控系統緊密集成后還可能產生新的安全相關功能。因此，當集成后的系統采用統一的硬件、統一的人機界面和統一的基礎數據平臺時，也要按照安全工程的要求，實施一個從需求到設計到實現貫穿完整生命周期的風險分析過程，包括初步危害分析、子系統危害分析、系統危害分析和操作與支持危害分析 （O&SHA）等。

　　初步危害分析的目的是識別出安全相關功能。一個功能如果滿足下列條件可以被認為是安全相關功能：

　　（1）該功能的失效也許/可能與其他事件組合在一起，導致發生人身傷害或地鐵運營中斷；

　　（2）為使導致人身傷害的總體風險降低到可接受的程度，需要在這個功能上施加一定的完整性假設。

　　子系統危害分析的目的是識別出執行安全相關功能的組件。按照IEC61508對安全完整性的基本定義，實際著重點在于安全系統（組件）執行安全功能的可靠性。

　　系統危害分析的目的是評估整個系統設計特別是子系統間接口設計的風險，對任何可能影響到功能和系統的附加危害進行評審。顯然，在開放網絡下，子系統間接口設計的新的風險主要來自信息技術安全。

　　1.4 風險分析和應對措施的重點

　　由于安全完整性等級是SIL2級，因此業界普遍認為與綜合監控系統集成后的目標系統的安全完整性也應是SIL2級。但是，還需要仔細分析，SIL等級分配實際與集成方案有關，并因此影響目標系統的風險分析和應對措施的重點。比如，如果采用所謂“戴帽”方案，即僅在操作員工作站做人機界面集成，且安全相關功能所有的功能性都被設計在服務器端，而用戶界面只是“一個遠程顯示系統或啞終端”時，實際用戶界面和原來的綜合監控系統就可以被定義在SIL0或SIL1級。由于原來的綜合監控系統不具有安全相關功能，因此，一定集成后的ATS的安全相關功能的執行依賴于綜合監控系統的某個組件，才需要為這個綜合監控組件分配同等的SIL等級，這時，這個組件在設計上的要求就不是功能安全，而是可靠性。

　　通常造成系統進入不安全狀態的原因可能有多種，比如硬件部件失效、系統部件接口出現問題、操作中的人為錯誤、環境應力改變等，但是，真正對目標系統的設計產生影響的原因主要還是來自軟件，包括軟件控制錯誤和軟件失效，因為其他原因在原來分離或淺集成的系統中大部分也是存在的。

　　因此，集成后的目標系統要達到服務安全性和可用性目標，風險分析和應對措施的重點應放在軟件可靠性和信息技術安全上，以此來保證安全相關功能執行的正確性和可用性。它們之間的關系如圖1所示。

　　在實際分析系統的安全性時，必須要考慮以下兩方面的因素：（1）信息技術安全的措施（如加密或認證）對運營安全的影響，如時間關鍵功能、資源可用性等，因為通常實施緩解措施總要付出某些代價；（2）安全相關功能對信息技術安全的影響，例如“某個操作功能是否會增加網絡攻擊的風險”，典型的例子如機密性遭到破壞， 竊密本身不會對系統的功能安全造成危害，但可能是下一步真正的網絡攻擊的前奏。

　　在實際分析系統的可用性時，必須要考慮能夠使系統處于不安全狀態的軟件控制錯誤和軟件失效。典型的軟件控制錯誤如：不能執行某一個要求的功能，執行了一種非要求的功能；時間和順序問題上的錯誤；不能識別某一種需要采取改正措施的風險條件；對于某種風險條件產生了錯誤反應。典型的軟件失效如：應用程序異常退出、應用程序僵尸、應用任務有資源泄露長期運行資源耗盡、運行負荷高響應性能下降等。

2 以行車調度為核心的綜合監控系統架構模型

　　2.1 系統架構模型

　　綜合監控系統與ATS的集成是一個通用的監控平臺與一個高度專業化的軟件進行集成，而ATS不僅有監控職能，還有計劃調度功能，因此比較好的集成方案是將ATS的基本監控功能劃歸綜合監控系統，形成一個集信號和其他專業子系統的實時數據于一體的綜合數據平臺，實現所有專業子系統底層設備的數據采集和以人工控制為主的基本監控，而ATS的自動功能（列車跟蹤、自排進路、自動調整等）及其他管理型模塊則作為基于該平臺的一個應用程序。綜合監控數據平臺向ATS（也包括其他應用程序）提供一個平臺中立的標準服務接口，ATS應用程序通過該接口訪問來自底層信號系統（ATP、CBI等）的原始實時數據、寫入經過ATS處理后的數據以及向底層信號系統發送控制命令。

　　圖2所示的是一個基于中間件的以行車調度為核心的綜合監控系統架構模型。

　　中間件的本質特征就是管理分布式基礎設施中的復雜性和異構性。因此圖2不是真實工程中從硬件角度描述的系統構成，而是系統構成的軟件抽象。例如，圖中的“主機/集群”可以代表所有的控制中心、車站或任意可能的中間層的系統服務器，它們可能既是底層服務器的客戶端，同時又作為聚合服務器為上層的應用程序提供數據訪問服務，因此可以表示分層分布式綜合監控系統的多層。

　　中間件總線表示為一個軟件總線，掛在總線上的客戶端應用程序和服務器應用程序之間實現客戶端/服務器模型。中間件必須在以下三種情況下確保客戶端服務器通信不影響應用層的軟件處理邏輯：客戶端和服務器被部署在同一臺計算機上；客戶和服務被部署在不同計算機上，但處于同一個安全邊界之內；客戶和服務被部署在不同計算機上，但可以連接在內聯網、外聯網甚至互聯網中。

　　在這個模型中，選擇的中間件技術平臺是由OPC基金會制定的統一架構標準OPC UA。該標準所提供的SOA架構和內置的信息技術安全是其被采用的重要原因，能夠以一種相對松耦合而又安全的方式集成兩個應用軟件是最佳的。此外，OPC UA還提供了信息建模和安全技術的擴展性，滿足系統對通用監控數據平臺的期望。

　　2.2 軟件架構

　　本系統采用的以行車調度為中心的綜合監控系統集成方案是由原來的綜合監控系統提供統一的硬件、統一的人機界面和統一的基礎數據平臺，而ATS軟件作為依賴于該平臺的一個應用程序，它們之間采用OPC UA 客戶/服務器模式進行通信。新的綜合監控系統軟件架構如圖3所示。

　　在此架構中，將ATS軟件以及其他基于綜合監控系統數據平臺的應用程序（如圖3中所示的“聯動組件”）與HMI一起統稱為 “SCADA應用程序”，在OPC UA的客戶/服務器模型中扮演Client角色，它們從服務器（甚至FEP）獲取實時/歷史數據/事件，按照特定的應用邏輯加工，然后再把結果寫回服務器；服務器組件通常既是UA Server也是UA Client，作為Server它們向Client提供實時/歷史數據/事件訪問，作為Client它們有從底層服務器（如FEP）獲取實時數據并進行通用的處理。而FEP作為UA Server負責現場數據的采集和控制命令輸出，流經FEP的數據流總是原始數據。

　　屬于ATS組件的高安全完整性命令也可以不經由SCADA服務器直接通過FEP輸出，但通信關系仍是UA 的客戶/服務器模型。分布式的ATS組件（如中心ATS主機和車站ATS分機）之間可以仍保留其專用的通信通道和方式，傳輸專用的信息，如圖3中所示的運行時刻表數據。

　　在這一架構中，綜合監控系統數據平臺是一個通用的平臺，因此它不應實現任何特定的安全相關功能，但必須為安全相關功能的執行提供信息技術安全，包括數據保護和高可用性。

3 目標系統組件間通信的安全性

　　EN50129-2標準規定了開放傳輸系統中對安全相關消息通信可能產生的各種威脅，并歸納出7種基本消息錯誤，即消息重復、消息刪除、消息插入、消息亂序、消息毀壞、消息延時、消息偽裝。這些消息錯誤既可能是通信機制的可靠性引起的，也可能是安全攻擊引起的，盡管原因不盡相同，但采取的防御措施有相同之處。

　　下面介紹的OPC UA技術平臺為組件間通信提供了強大的安全性和健壯性，可以為安全相關消息的通信提供很大程度上的保證。

　　3.1 OPC UA簡介

　　OPC UA是OPC基金會2006年推出的新一代技術，并已成為IEC標準，用于安全、可靠和廠商獨立的原始數據和預處理信息的傳輸，范圍從傳感器和現場級的PLC和嵌入式設備直到控制系統并延伸到生產計劃系統，所有類型的信息可以隨時隨地為每個授權的用戶和每個授權的人所使用。它的重點是建立互操作性標準，其主要技術特點如：面向服務的體系結構、面向對象的信息模型、抽象和映射、安全、裁剪專規（Profile）、魯棒性。

　　OPC UA的一個目標就是為過程控制和管理系統的集成提供一個一致的機制，并確保為這類應用提供健壯和有效的安全性。同時該安全基礎設施也具有靈活性，可以支持各種不同組織在不同層次所需要的安全策略。這樣，OPC UA可以被部署在不同的環境，從客戶端和服務器駐留在同一主機的單機環境、由某個安全邊界防護的封閉的運營網絡環境，直到使用公網基礎設施的全球環境中運行的應用程序。根據不同的環境和應用要求，通信服務可以提供不同的保護，以保證解決方案的安全性。

　　3.1.1 OPC UA的安全模型

　　OPC UA技術采用了信息技術中成熟的安全理念，為系統提供了保護，防止未經授權的訪問，防止破壞和對過程數據的無意修改。其安全概念包含對用戶和應用程序的身份驗證、消息簽名和對傳輸數據本身進行加密。OPC UA的安全性基于互聯網公認的安全通信標準，如SSL、TLS和AES。并且安全機制是標準的一部分，被內置到OPC UA核心，對供應商是強制性的，但用戶可以根據各自的情況使用各種安全功能的組合。

　　OPC UA的安全模型針對現代工業設備目前所面臨的典型的系統安全威脅，包括主動攻擊和被動攻擊，如消息洪水、消息竊聽、消息欺騙、消息篡改、消息重放、畸形消息、服務器剖析、會話劫持、流氓服務器、盜用證書等，并制訂了相應的緩解措施。OPC UA核心的安全功能涉及如下信息技術安全目標：身份認證、授權、保密性、完整性、可用性和審計能力（不可抵賴性）。

　　對信息技術安全，OPC UA針對工業控制的特點，補充了大多數支持Web平臺所提供的安全基礎設施，采用了分別在傳輸層、應用層和用戶層提供多層保護的“縱深防御”的策略，在基本傳輸連接基礎上，UA客戶端和服務器需要建立一個安全通道（通信層上的一個虛擬的端到端連接），并建立一個會話（應用層上的一個虛擬通信關聯）。安全通道用于定義安全模式和安全方針。安全模式描述如何對消息進行加密。OPC UA定義了三個選項可供選擇：“無”、“簽名”和“簽名且加密”。安全方針則定義了加密消息的算法。啟動時，客戶端需要服務器實例證書的公鑰。然后，客戶端發送自己的實例證書，由服務器根據它來決定是否信任該客戶端。

　　多層保護的結構如圖4所示。

　　表1是一個針對安全目標OPC UA所采用的應對方案。

　　此外，與傳統中間件技術平臺（如CORBA或DCOM）不同的是，OPC UA可以穿越防火墻。OPC UA采用了一種基于TCP的、優化的二進制協議，通過已在IANA注冊的4840端口進行數據交換，在防火墻中只需要打開這一個端口。也可選擇支持Web服務和HTTP。集成的加密機制可以確保互聯網上的安全通信。

　　3.1.2 OPC UA通信的健壯性

　　OPC UA定義了一個健壯的體系結構，具有可靠的通信機制，可配置超時和自動錯誤檢測。消除錯誤的機制能自動恢復OPC UA客戶端和OPC UA服務器之間的通信連接而不會丟失數據。采用客戶-服務器模式的數據訪問時，客戶端發送一個服務請求，并從服務器接收異步響應。每一個服務調用都包含一個可配置的超時時間，客戶端將等待直到響應到達。序列號用于識別對應的請求/響應消息對。當采用“訂閱-發布”模式讀取事件或值變化通知時，每個發布的數據響應由客戶端用下一個發布請求進行確認。萬一連接中斷或傳送失敗，服務器保留未確認的消息，并在連接再次恢復時重新發送。在此期間收集的數據將被服務器緩沖或排隊，使得在短暫的網絡中斷中不丟失任何數據。

　　OPC UA要求一個“有狀態”模型作為增強解決方案的魯棒性的一個特征。狀態信息被保存在應用程序會話內，例如訂閱，用戶憑證和延續點可以在操作上跨越多個請求。會話被定義為客戶端和服務器之間的邏輯連接。值得強調的是，每個會話都是獨立于底層通信協議的。這些協議的故障不會導致會話自動終止。會話終止是基于客戶機或服務器的請求，或基于客戶端的失活。

　　3.2高完整性控制命令的傳輸

　　OPC UA標準對各種信息技術安全威脅的防御和緩解措施參見OPC UA規范第2部分[10]。根據分析對比發現，這些措施已經涵蓋了EN50129-2建議的主要防護要求，可以保證安全相關消息的確實性、完整性和有序性。但在消息的合時性方面可能需要從功能安全角度施加補充措施（但也不一定，依賴于具體的安全相關控制命令的傳輸要求），因為OPC UA的高可用性的主要目標是實時數據流不因通信故障而中斷。

4目標系統的安全性和可靠性設計要求

　　為滿足目標系統所要求的安全完整性，需要實施完整的安全生命周期過程，對此，EN50128提供了某些強制和建議要求。例如，可以實施一個圖5所示的軟件失效模式及影響分析過程，從而確定對軟件的安全性需求。

　　但是軟件的安全性和可靠性問題存在共性，例如軟件的失效原因可能包括：功能和性能缺陷、軟件結構缺省、數據缺陷、軟件實現和編碼缺陷、軟硬件接口缺陷等。其中靜態缺陷可以比較容易克服，比如嚴格的質量過程；但動態缺陷往往比較難于發現，比如可能隨機產生的某個事件引起程序執行中的時序錯誤。因此在風險分析進行到設計過程時應適當運用如時序分析、事件分析、Petri網分析等工具。

　　下面列出一些對前面給出的“以行車調度為核心的綜合監控系統架構模型”的實施建議。

　　（1）人工操作與自動控制命令互鎖

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

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

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

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

　　（２）關鍵控制操作

　　對于安全相關的控制功能，要求操作員必須介入，實行類似如下步驟的“執行前檢查”過程，并且用戶輸入一個控制命令要服從特定的時間約束。

　　①操作員選擇執行一個命令；

　　②命令發送到執行裝置；

　　③執行裝置驗證控制狀態；

　　④執行裝置將檢查結果返回給控制系統；

　　⑤控制系統將檢查結果顯示給操作員請求證實（Confirm）；

　　⑥控制系統將證實發送到執行裝置；

　　⑦執行裝置執行該命令；

　　⑧控制系統驗證返回條件。

　　（3）設定值

　　設定值用于改變底層裝置中的模擬量設定值，或綜合監控數據平臺本身實時數據庫中的某些狀態值，比如設備或區域的維修掛牌。設定值應在計算機切換或掉電恢復后依舊保持。

　　（4）連接和會話

　　考慮到增強信息技術安全對性能的影響，對于安全相關的關鍵控制，如設置/解除臨時限速，應采用與普通數據傳輸不同的獨立的OPC UA安全通道和會話，并采用單獨的加密算法。

　　（5）并行發送

　　當安全相關命令有強烈的限時到達要求，且并行發送對底層信號系統無害時（即可以處理相同命令的兩次發送），則可以采用冗余雙網并行發送控制命令，以解決EN50129-2指出的消息延時這一基本消息錯誤。

5 結論

　　以行車調度為核心的城市軌道交通綜合監控系統是一個牽涉到多種技術領域，由多種設備、多種硬軟件、多種設施組成的復雜系統，真正實施時還要面臨綜合監控廠家和信號廠家密切協作的問題。在安全性、可靠性方面，最關鍵的是保證兩點：第一，不引起或不提供虛假輸出，包括向現場輸出和向用戶界面輸出；第二，當操作員想要執行一個安全相關操作時，系統處于可用的狀態。當然，在開放的網絡環境又引入了信息技術安全的問題，對此采用的OPC UA協議標準幾乎是一個“開箱即用”的解決方案。

參考文獻

　　[1] 周庭梁，孫軍峰，孫春榮.談以行車指揮為核心的城軌交通綜合監控系統[J].現代城市軌道交通，2009（3）：14-17.

　　[2] 郭永泉.城市軌道交通綜合監控系統集成信號ATS的研究[J].現代城市軌道交通，2008（6）：34-36.

　　[3] 魏祥斌.集成信號列車自動監控子系統的綜合監控系統方案[J].現代城市軌道交通，2012（8）：86-89.

　　[4] 趙惠祥，余世昌.城市軌道交通系統的安全性與可靠性[J].城市軌道交通研究，2006（1）：7-10.

　　[5] CEI IEC61508： Functional safety of electrical/electronic/programmable electronic safety-related systems（Version 12.0）[S]. 1997.