謝紅兵(北京和利時系統(tǒng)工程有限公司,北京 100176)
以行車調(diào)度為中心的綜合監(jiān)控系統(tǒng)在開放網(wǎng)絡(luò)環(huán)境中的安全性研究*
謝紅兵
(北京和利時系統(tǒng)工程有限公司,北京 100176)
探討了在城市軌道交通綜合自動化系統(tǒng)中將傳統(tǒng)以電調(diào)、環(huán)調(diào)為核心的綜合監(jiān)控系統(tǒng)與信號系統(tǒng)中ATS系統(tǒng)集成后在開放網(wǎng)絡(luò)環(huán)境下的安全性問題,識別了關(guān)注的重點,給出了一個基于OPC UA的具體實現(xiàn)方案。最后給出了若干實施建議。
綜合監(jiān)控系統(tǒng);信號系統(tǒng);ATS;開放網(wǎng)絡(luò)環(huán)境;安全性;可靠性;OPC UA
目前國內(nèi)的城市軌道交通綜合自動化普遍采用的是以電調(diào)、環(huán)調(diào)為核心的綜合監(jiān)控系統(tǒng)方案,即綜合監(jiān)控系統(tǒng)與信號系統(tǒng)中的 ATS(自動列車監(jiān)督)子系統(tǒng)互聯(lián),進行信息交換。這種方案沒有將地鐵運行中最重要的環(huán)節(jié)“行車調(diào)度指揮”真正集成,使得綜合自動化系統(tǒng)最重要的系統(tǒng)聯(lián)動功能難以充分發(fā)揮其作用[1]。要提升綜合監(jiān)控系統(tǒng)的運營維護管理水平,提高集成度,形成以行車調(diào)度指揮為核心的綜合監(jiān)控系統(tǒng)是必由之路。
以行車調(diào)度指揮為核心的綜合監(jiān)控系統(tǒng)的顯著特征是集成信號系統(tǒng)的ATS子系統(tǒng),同時集成與行車指揮有關(guān)的系統(tǒng),從而實現(xiàn)對軌道交通中環(huán)境、供電、設(shè)備、乘客、列車的全面監(jiān)控,同時通過緊密集成后形成的大范圍信息共享,可以進一步實現(xiàn)各個專業(yè)子系統(tǒng)之間的快速聯(lián)動,真正做到為運營指揮部門服務(wù),提高軌道交通運營指揮的自動化水平[2]。
實施這樣一個以行車調(diào)度指揮為核心的綜合監(jiān)控系統(tǒng)將會面臨兩個挑戰(zhàn)。
第一個挑戰(zhàn)是采用何種集成技術(shù)方案。這是因為傳統(tǒng)的綜合監(jiān)控系統(tǒng)和信號系統(tǒng)是由不同的廠家提供的。對此參考文獻[3]給出了戴帽、內(nèi)嵌和完全集成 3種實施方案,并在集成系統(tǒng)的接口范圍、接口劃分和功能設(shè)置上都給出了較為具體的方案;參考文獻[2]則給出了一個分階段實施方案,但大體思路與參考文獻[3]類似;而南瑞和卡斯科已經(jīng)在北京地鐵6號線實現(xiàn)了一個接近完全集成后的系統(tǒng),并取得了不錯的效果。集成技術(shù)方案的主要難點一般聚焦于兩點,一是如何協(xié)調(diào)和分配安全完整性等級,二是傳統(tǒng)綜合監(jiān)控系統(tǒng)和ATS系統(tǒng)軟件在多大程度上向?qū)Ψ介_放。
第二個挑戰(zhàn)就是信息安全(Security)。因為無論傳統(tǒng)的綜合監(jiān)控系統(tǒng)還是ATS系統(tǒng)目前都是運行在一個封閉的網(wǎng)絡(luò)之內(nèi),對外沒有互聯(lián)互通。由于沒有現(xiàn)實的信息安全威脅,系統(tǒng)在設(shè)計、實現(xiàn)與部署過程中,其主要指標是可用性、功能、性能、功能安全(Safety)、實時性等,而無需過多考慮網(wǎng)絡(luò)攻擊、信息安全等問題。但是,隨著近年來以數(shù)字化、網(wǎng)絡(luò)化和集成化為特征的 ICT(信息和通信技術(shù))的快速發(fā)展,互聯(lián)網(wǎng)、云計算等應(yīng)用的日益普及,綜合監(jiān)控系統(tǒng)不能不考慮進一步對其安全邊界之外的用戶開放,無論是路網(wǎng)內(nèi)各條線路之間水平方向的信息交換,還是作為基礎(chǔ)信息平臺在垂直方向向信息系統(tǒng)擴展,趨勢都是與線網(wǎng)內(nèi)外的其他系統(tǒng)互聯(lián)互通,特別是當以行車調(diào)度指揮為核心的綜合監(jiān)控系統(tǒng)逐步形成線路內(nèi)唯一的集成信息共享平臺后,這一趨勢看上去更加明顯。
因此,新一代的以行車調(diào)度為中心的綜合監(jiān)控系統(tǒng)在集成方案和技術(shù)平臺的選擇上都應(yīng)該在開放的網(wǎng)絡(luò)環(huán)境下考慮,并將保障信息安全作為一項關(guān)鍵的設(shè)計原則。
1.1安全性和可靠性
對于城市軌道交通系統(tǒng),安全性指在系統(tǒng)運營過程中,保障“乘客和員工不受傷害以及設(shè)備(設(shè)施)不遭破壞”的能力。保障“乘客和員工不受傷害以及設(shè)備(設(shè)施)不遭破壞”的能力包含了兩個方面,即不發(fā)生意外的安全(Safety)和免遭破壞的安全(Security)[4]。為劃清這兩個術(shù)語之間的區(qū)別,本文以下將“Safety”稱為“功能安全”,將“Security”稱為“信息技術(shù)安全”。
根據(jù)ISO8402 的定義,功能安全是“使傷害或損害的風險限制在可接受的水平內(nèi)”。系統(tǒng)的安全性視為是其一種內(nèi)在的特性,這種屬性確定了系統(tǒng)在運行中,避免觸發(fā)人身傷亡、重大財產(chǎn)損失或環(huán)境污染等事故的能力。功能安全由安全完整性來度量。根據(jù) IEC61508中的基本定義,安全完整性是指在規(guī)定的條件下、規(guī)定的時間內(nèi),安全系統(tǒng)成功實現(xiàn)所要求的安全功能的概率[5]。
而信息技術(shù)安全是指自動化系統(tǒng)本身也需要加以保護,以防止濫用、安全攻擊、未經(jīng)授權(quán)的訪問和泄密等,保護數(shù)據(jù)和服務(wù)系統(tǒng)。信息技術(shù)安全措施的目標是提高保密性 (特定的機器/人類用戶的數(shù)據(jù)和服務(wù)的訪問限制)、完整性(數(shù)據(jù)的精度/完整以及服務(wù)的正確操作)和可用性(測量系統(tǒng)在特定時間內(nèi)執(zhí)行功能的能力)[6]。
在軌道交通領(lǐng)域普遍采用的基于 IEC61508的歐標EN51026中沒有規(guī)定確保系統(tǒng)信息技術(shù)安全的要求,但將其作為表征鐵路系統(tǒng)應(yīng)對破壞行為和人們不合理行為自我恢復(fù)能力的一個要素[7],因此是系統(tǒng)危害分析中的一個重要方面。從根本上說,信息技術(shù)安全性是為降低攻擊所造成的損害。通過識別對系統(tǒng)的威脅,以及識別系統(tǒng)對這些威脅的漏洞,并提供相應(yīng)的對策,以直接減少漏洞、抵消威脅,或從成功的攻擊中恢復(fù)。通過多年來通用的信息系統(tǒng)安全性的經(jīng)驗,已經(jīng)形成了一組相當穩(wěn)定的安全目標,并形成一系列相關(guān)的標準。像地鐵綜合監(jiān)控系統(tǒng)這類工業(yè)自動化系統(tǒng)要達到安全性也必須滿足這樣一組目標,這些目標主要聚焦在可用性、完整性、保密性、認證、授權(quán)和不可抵賴性幾個方面(按重要性排列)。不可抵賴性主要體現(xiàn)在事后審計上,因此一般來說重要性最低。而對工業(yè)自動化系統(tǒng)設(shè)備的可用性、實時性、可控性等特性要求很高,因此可用性最為重要。
與安全性有區(qū)別但又有密切關(guān)系的是可靠性??煽啃允侵讣榷ōh(huán)境下既定時間內(nèi)一個(技術(shù))系統(tǒng)正常運行的概率。依賴于所提供系統(tǒng)或由該系統(tǒng)本身的正確操作,包括低故障率、高容錯性(即能夠保持正常運行,即使發(fā)生故障時)和魯棒性(基本功能的能力,以保證不發(fā)生故障)[6]。對于城市軌道交通系統(tǒng),可靠性指在系統(tǒng)運營過程中,保障“乘客準時到達目的地”的能力。通常所講的“保障乘客安全正點旅行”即包含了系統(tǒng)安全性與可靠性兩方面的概念。
1.2開放網(wǎng)絡(luò)系統(tǒng)
開放網(wǎng)絡(luò)系統(tǒng)按照歐標EN50159的定義,是指“具有未知、可變或非受信屬性且擁有未知數(shù)量的參與者,用于未知電信服務(wù)并對未經(jīng)授權(quán)的訪問進行評估的系統(tǒng)”[8]。顯然與封閉傳輸系統(tǒng)相比,這諸多“未知”因素增加的安全風險主要來自信息技術(shù)安全方面。按照EN50159的安全相關(guān)系統(tǒng)在通信上的防護要求,主要體現(xiàn)在防御傳輸錯誤和防御未經(jīng)授權(quán)的訪問上。實際上還應(yīng)該加上可用性,因為惡意的網(wǎng)絡(luò)攻擊(比如消息洪水)可能造成某臺功能服務(wù)器性能顯著下降,從而使安全相關(guān)功能受損或不可用。
1.3安全相關(guān)系統(tǒng)
傳統(tǒng)上 ATS雖然不是故障安全系統(tǒng),但仍具有安全相關(guān)功能,如參考文獻[9]中列出的中途停車、取消臨時限速、解除區(qū)間封鎖或施工區(qū)等可能潛在地導(dǎo)致系統(tǒng)危害的操作,故其安全完整性等級是 SIL2級。并且,與傳統(tǒng)綜合監(jiān)控系統(tǒng)緊密集成后還可能產(chǎn)生新的安全相關(guān)功能。因此,當集成后的系統(tǒng)采用統(tǒng)一的硬件、統(tǒng)一的人機界面和統(tǒng)一的基礎(chǔ)數(shù)據(jù)平臺時,也要按照安全工程的要求,實施一個從需求到設(shè)計到實現(xiàn)貫穿完整生命周期的風險分析過程,包括初步危害分析、子系統(tǒng)危害分析、系統(tǒng)危害分析和操作與支持危害分析(O&SHA)等。
初步危害分析的目的是識別出安全相關(guān)功能。一個功能如果滿足下列條件可以被認為是安全相關(guān)功能:
(1)該功能的失效也許/可能與其他事件組合在一起,導(dǎo)致發(fā)生人身傷害或地鐵運營中斷;
(2)為使導(dǎo)致人身傷害的總體風險降低到可接受的程度,需要在這個功能上施加一定的完整性假設(shè)。
子系統(tǒng)危害分析的目的是識別出執(zhí)行安全相關(guān)功能的組件。按照IEC61508對安全完整性的基本定義,實際著重點在于安全系統(tǒng)(組件)執(zhí)行安全功能的可靠性。
系統(tǒng)危害分析的目的是評估整個系統(tǒng)設(shè)計特別是子系統(tǒng)間接口設(shè)計的風險,對任何可能影響到功能和系統(tǒng)的附加危害進行評審。顯然,在開放網(wǎng)絡(luò)下,子系統(tǒng)間接口設(shè)計的新的風險主要來自信息技術(shù)安全。
1.4風險分析和應(yīng)對措施的重點
由于安全完整性等級是SIL2級,因此業(yè)界普遍認為與綜合監(jiān)控系統(tǒng)集成后的目標系統(tǒng)的安全完整性也應(yīng)是SIL2級。但是,還需要仔細分析,SIL等級分配實際與集成方案有關(guān),并因此影響目標系統(tǒng)的風險分析和應(yīng)對措施的重點。比如,如果采用所謂“戴帽”方案,即僅在操作員工作站做人機界面集成,且安全相關(guān)功能所有的功能性都被設(shè)計在服務(wù)器端,而用戶界面只是“一個遠程顯示系統(tǒng)或啞終端”時,實際用戶界面和原來的綜合監(jiān)控系統(tǒng)就可以被定義在SIL0或SIL1級。由于原來的綜合監(jiān)控系統(tǒng)不具有安全相關(guān)功能,因此,一定集成后的ATS的安全相關(guān)功能的執(zhí)行依賴于綜合監(jiān)控系統(tǒng)的某個組件,才需要為這個綜合監(jiān)控組件分配同等的SIL等級,這時,這個組件在設(shè)計上的要求就不是功能安全,而是可靠性。
通常造成系統(tǒng)進入不安全狀態(tài)的原因可能有多種,比如硬件部件失效、系統(tǒng)部件接口出現(xiàn)問題、操作中的人為錯誤、環(huán)境應(yīng)力改變等,但是,真正對目標系統(tǒng)的設(shè)計產(chǎn)生影響的原因主要還是來自軟件,包括軟件控制錯誤和軟件失效,因為其他原因在原來分離或淺集成的系統(tǒng)中大部分也是存在的。
因此,集成后的目標系統(tǒng)要達到服務(wù)安全性和可用性目標,風險分析和應(yīng)對措施的重點應(yīng)放在軟件可靠性和信息技術(shù)安全上,以此來保證安全相關(guān)功能執(zhí)行的正確性和可用性。它們之間的關(guān)系如圖1所示。
圖1 服務(wù)安全性和可用性與軟件可靠性和信息技術(shù)安全之間的關(guān)系
在實際分析系統(tǒng)的安全性時,必須要考慮以下兩方面的因素:(1)信息技術(shù)安全的措施(如加密或認證)對運營安全的影響,如時間關(guān)鍵功能、資源可用性等,因為通常實施緩解措施總要付出某些代價;(2)安全相關(guān)功能對信息技術(shù)安全的影響,例如“某個操作功能是否會增加網(wǎng)絡(luò)攻擊的風險”,典型的例子如機密性遭到破壞,竊密本身不會對系統(tǒng)的功能安全造成危害,但可能是下一步真正的網(wǎng)絡(luò)攻擊的前奏。
在實際分析系統(tǒng)的可用性時,必須要考慮能夠使系統(tǒng)處于不安全狀態(tài)的軟件控制錯誤和軟件失效。典型的軟件控制錯誤如:不能執(zhí)行某一個要求的功能,執(zhí)行了一種非要求的功能;時間和順序問題上的錯誤;不能識別某一種需要采取改正措施的風險條件;對于某種風險條件產(chǎn)生了錯誤反應(yīng)。典型的軟件失效如:應(yīng)用程序異常退出、應(yīng)用程序僵尸、應(yīng)用任務(wù)有資源泄露長期運行資源耗盡、運行負荷高響應(yīng)性能下降等。
2.1系統(tǒng)架構(gòu)模型
綜合監(jiān)控系統(tǒng)與ATS的集成是一個通用的監(jiān)控平臺與一個高度專業(yè)化的軟件進行集成,而ATS不僅有監(jiān)控職能,還有計劃調(diào)度功能,因此比較好的集成方案是將ATS的基本監(jiān)控功能劃歸綜合監(jiān)控系統(tǒng),形成一個集信號和其他專業(yè)子系統(tǒng)的實時數(shù)據(jù)于一體的綜合數(shù)據(jù)平臺,實現(xiàn)所有專業(yè)子系統(tǒng)底層設(shè)備的數(shù)據(jù)采集和以人工控制為主的基本監(jiān)控,而ATS的自動功能 (列車跟蹤、自排進路、自動調(diào)整等)及其他管理型模塊則作為基于該平臺的一個應(yīng)用程序。綜合監(jiān)控數(shù)據(jù)平臺向ATS(也包括其他應(yīng)用程序)提供一個平臺中立的標準服務(wù)接口,ATS應(yīng)用程序通過該接口訪問來自底層信號系統(tǒng)(ATP、CBI等)的原始實時數(shù)據(jù)、寫入經(jīng)過 ATS處理后的數(shù)據(jù)以及向底層信號系統(tǒng)發(fā)送控制命令。
圖2所示的是一個基于中間件的以行車調(diào)度為核心的綜合監(jiān)控系統(tǒng)架構(gòu)模型。
圖2 架構(gòu)模型的模塊圖
中間件的本質(zhì)特征就是管理分布式基礎(chǔ)設(shè)施中的復(fù)雜性和異構(gòu)性。因此圖2不是真實工程中從硬件角度描述的系統(tǒng)構(gòu)成,而是系統(tǒng)構(gòu)成的軟件抽象。例如,圖中的“主機/集群”可以代表所有的控制中心、車站或任意可能的中間層的系統(tǒng)服務(wù)器,它們可能既是底層服務(wù)器的客戶端,同時又作為聚合服務(wù)器為上層的應(yīng)用程序提供數(shù)據(jù)訪問服務(wù),因此可以表示分層分布式綜合監(jiān)控系統(tǒng)的多層。
中間件總線表示為一個軟件總線,掛在總線上的客戶端應(yīng)用程序和服務(wù)器應(yīng)用程序之間實現(xiàn)客戶端/服務(wù)器模型。中間件必須在以下三種情況下確??蛻舳朔?wù)器通信不影響應(yīng)用層的軟件處理邏輯:客戶端和服務(wù)器被部署在同一臺計算機上;客戶和服務(wù)被部署在不同計算機上,但處于同一個安全邊界之內(nèi);客戶和服務(wù)被部署在不同計算機上,但可以連接在內(nèi)聯(lián)網(wǎng)、外聯(lián)網(wǎng)甚至互聯(lián)網(wǎng)中。
在這個模型中,選擇的中間件技術(shù)平臺是由OPC基金會制定的統(tǒng)一架構(gòu)標準 OPC UA。該標準所提供的SOA架構(gòu)和內(nèi)置的信息技術(shù)安全是其被采用的重要原因,能夠以一種相對松耦合而又安全的方式集成兩個應(yīng)用軟件是最佳的。此外,OPC UA還提供了信息建模和安全技術(shù)的擴展性,滿足系統(tǒng)對通用監(jiān)控數(shù)據(jù)平臺的期望。
2.2軟件架構(gòu)
本系統(tǒng)采用的以行車調(diào)度為中心的綜合監(jiān)控系統(tǒng)集成方案是由原來的綜合監(jiān)控系統(tǒng)提供統(tǒng)一的硬件、統(tǒng)一的人機界面和統(tǒng)一的基礎(chǔ)數(shù)據(jù)平臺,而ATS軟件作為依賴于該平臺的一個應(yīng)用程序,它們之間采用OPC UA客戶/服務(wù)器模式進行通信。新的綜合監(jiān)控系統(tǒng)軟件架構(gòu)如圖3所示。
圖3 軟件架構(gòu)
在此架構(gòu)中,將ATS軟件以及其他基于綜合監(jiān)控系統(tǒng)數(shù)據(jù)平臺的應(yīng)用程序(如圖3中所示的“聯(lián)動組件”)與HMI一起統(tǒng)稱為 “SCADA應(yīng)用程序”,在OPC UA的客戶/服務(wù)器模型中扮演 Client角色,它們從服務(wù)器(甚至FEP)獲取實時/歷史數(shù)據(jù)/事件,按照特定的應(yīng)用邏輯加工,然后再把結(jié)果寫回服務(wù)器;服務(wù)器組件通常既是UA Server也是 UA Client,作為 Server它們向 Client提供實時/歷史數(shù)據(jù)/事件訪問,作為 Client它們有從底層服務(wù)器(如FEP)獲取實時數(shù)據(jù)并進行通用的處理。而FEP作為 UA Server負責現(xiàn)場數(shù)據(jù)的采集和控制命令輸出,流經(jīng)FEP的數(shù)據(jù)流總是原始數(shù)據(jù)。
屬于ATS組件的高安全完整性命令也可以不經(jīng)由SCADA服務(wù)器直接通過 FEP輸出,但通信關(guān)系仍是UA的客戶/服務(wù)器模型。分布式的ATS組件(如中心ATS主機和車站ATS分機)之間可以仍保留其專用的通信通道和方式,傳輸專用的信息,如圖3中所示的運行時刻表數(shù)據(jù)。
在這一架構(gòu)中,綜合監(jiān)控系統(tǒng)數(shù)據(jù)平臺是一個通用的平臺,因此它不應(yīng)實現(xiàn)任何特定的安全相關(guān)功能,但必須為安全相關(guān)功能的執(zhí)行提供信息技術(shù)安全,包括數(shù)據(jù)保護和高可用性。
EN50129-2標準規(guī)定了開放傳輸系統(tǒng)中對安全相關(guān)消息通信可能產(chǎn)生的各種威脅,并歸納出7種基本消息錯誤,即消息重復(fù)、消息刪除、消息插入、消息亂序、消息毀壞、消息延時、消息偽裝。這些消息錯誤既可能是通信機制的可靠性引起的,也可能是安全攻擊引起的,盡管原因不盡相同,但采取的防御措施有相同之處。
下面介紹的OPC UA技術(shù)平臺為組件間通信提供了強大的安全性和健壯性,可以為安全相關(guān)消息的通信提供很大程度上的保證。
3.1OPC UA簡介
OPC UA是 OPC基金會 2006年推出的新一代技術(shù),并已成為IEC標準,用于安全、可靠和廠商獨立的原始數(shù)據(jù)和預(yù)處理信息的傳輸,范圍從傳感器和現(xiàn)場級的PLC和嵌入式設(shè)備直到控制系統(tǒng)并延伸到生產(chǎn)計劃系統(tǒng),所有類型的信息可以隨時隨地為每個授權(quán)的用戶和每個授權(quán)的人所使用。它的重點是建立互操作性標準,其主要技術(shù)特點如:面向服務(wù)的體系結(jié)構(gòu)、面向?qū)ο蟮男畔⒛P?、抽象和映射、安全、裁剪專?guī)(Profile)、魯棒性。
OPC UA的一個目標就是為過程控制和管理系統(tǒng)的集成提供一個一致的機制,并確保為這類應(yīng)用提供健壯和有效的安全性。同時該安全基礎(chǔ)設(shè)施也具有靈活性,可以支持各種不同組織在不同層次所需要的安全策略。這樣,OPC UA可以被部署在不同的環(huán)境,從客戶端和服務(wù)器駐留在同一主機的單機環(huán)境、由某個安全邊界防護的封閉的運營網(wǎng)絡(luò)環(huán)境,直到使用公網(wǎng)基礎(chǔ)設(shè)施的全球環(huán)境中運行的應(yīng)用程序。根據(jù)不同的環(huán)境和應(yīng)用要求,通信服務(wù)可以提供不同的保護,以保證解決方案的安全性。
3.1.1OPC UA的安全模型
OPC UA技術(shù)采用了信息技術(shù)中成熟的安全理念,為系統(tǒng)提供了保護,防止未經(jīng)授權(quán)的訪問,防止破壞和對過程數(shù)據(jù)的無意修改。其安全概念包含對用戶和應(yīng)用程序的身份驗證、消息簽名和對傳輸數(shù)據(jù)本身進行加密。OPC UA的安全性基于互聯(lián)網(wǎng)公認的安全通信標準,如SSL、TLS和AES。并且安全機制是標準的一部分,被內(nèi)置到OPC UA核心,對供應(yīng)商是強制性的,但用戶可以根據(jù)各自的情況使用各種安全功能的組合。
OPC UA的安全模型針對現(xiàn)代工業(yè)設(shè)備目前所面臨的典型的系統(tǒng)安全威脅,包括主動攻擊和被動攻擊,如消息洪水、消息竊聽、消息欺騙、消息篡改、消息重放、畸形消息、服務(wù)器剖析、會話劫持、流氓服務(wù)器、盜用證書等,并制訂了相應(yīng)的緩解措施。OPC UA核心的安全功能涉及如下信息技術(shù)安全目標:身份認證、授權(quán)、保密性、完整性、可用性和審計能力(不可抵賴性)。
對信息技術(shù)安全,OPC UA針對工業(yè)控制的特點,補充了大多數(shù)支持Web平臺所提供的安全基礎(chǔ)設(shè)施,采用了分別在傳輸層、應(yīng)用層和用戶層提供多層保護的“縱深防御”的策略,在基本傳輸連接基礎(chǔ)上,UA客戶端和服務(wù)器需要建立一個安全通道(通信層上的一個虛擬的端到端連接),并建立一個會話(應(yīng)用層上的一個虛擬通信關(guān)聯(lián))。安全通道用于定義安全模式和安全方針。安全模式描述如何對消息進行加密。OPC UA定義了三個選項可供選擇:“無”、“簽名”和“簽名且加密”。安全方針則定義了加密消息的算法。啟動時,客戶端需要服務(wù)器實例證書的公鑰。然后,客戶端發(fā)送自己的實例證書,由服務(wù)器根據(jù)它來決定是否信任該客戶端。
多層保護的結(jié)構(gòu)如圖4所示。
圖4 OPC UA安全概念
表1是一個針對安全目標OPC UA所采用的應(yīng)對方案。
表1 OPC UA 對安全目標所采用的應(yīng)對方案列表
此外,與傳統(tǒng)中間件技術(shù)平臺 (如CORBA或DCOM)不同的是,OPC UA可以穿越防火墻。OPC UA采用了一種基于TCP的、優(yōu)化的二進制協(xié)議,通過已在IANA注冊的4840端口進行數(shù)據(jù)交換,在防火墻中只需要打開這一個端口。也可選擇支持Web服務(wù)和HTTP。集成的加密機制可以確?;ヂ?lián)網(wǎng)上的安全通信。
3.1.2OPC UA通信的健壯性
OPC UA定義了一個健壯的體系結(jié)構(gòu),具有可靠的通信機制,可配置超時和自動錯誤檢測。消除錯誤的機制能自動恢復(fù)OPC UA客戶端和OPC UA服務(wù)器之間的通信連接而不會丟失數(shù)據(jù)。采用客戶-服務(wù)器模式的數(shù)據(jù)訪問時,客戶端發(fā)送一個服務(wù)請求,并從服務(wù)器接收異步響應(yīng)。每一個服務(wù)調(diào)用都包含一個可配置的超時時間,客戶端將等待直到響應(yīng)到達。序列號用于識別對應(yīng)的請求/響應(yīng)消息對。當采用“訂閱-發(fā)布”模式讀取事件或值變化通知時,每個發(fā)布的數(shù)據(jù)響應(yīng)由客戶端用下一個發(fā)布請求進行確認。萬一連接中斷或傳送失敗,服務(wù)器保留未確認的消息,并在連接再次恢復(fù)時重新發(fā)送。在此期間收集的數(shù)據(jù)將被服務(wù)器緩沖或排隊,使得在短暫的網(wǎng)絡(luò)中斷中不丟失任何數(shù)據(jù)。
OPC UA要求一個 “有狀態(tài)”模型作為增強解決方案的魯棒性的一個特征。狀態(tài)信息被保存在應(yīng)用程序會話內(nèi),例如訂閱,用戶憑證和延續(xù)點可以在操作上跨越多個請求。會話被定義為客戶端和服務(wù)器之間的邏輯連接。值得強調(diào)的是,每個會話都是獨立于底層通信協(xié)議的。這些協(xié)議的故障不會導(dǎo)致會話自動終止。會話終止是基于客戶機或服務(wù)器的請求,或基于客戶端的失活。
3.2高完整性控制命令的傳輸
OPC UA標準對各種信息技術(shù)安全威脅的防御和緩解措施參見 OPC UA規(guī)范第2部分[10]。根據(jù)分析對比發(fā)現(xiàn),這些措施已經(jīng)涵蓋了EN50129-2建議的主要防護要求,可以保證安全相關(guān)消息的確實性、完整性和有序性。但在消息的合時性方面可能需要從功能安全角度施加補充措施(但也不一定,依賴于具體的安全相關(guān)控制命令的傳輸要求),因為OPC UA的高可用性的主要目標是實時數(shù)據(jù)流不因通信故障而中斷。
為滿足目標系統(tǒng)所要求的安全完整性,需要實施完整的安全生命周期過程,對此,EN50128提供了某些強制和建議要求。例如,可以實施一個圖5所示的軟件失效模式及影響分析過程,從而確定對軟件的安全性需求。
圖5 軟件失效模式及影響分析過程
但是軟件的安全性和可靠性問題存在共性,例如軟件的失效原因可能包括:功能和性能缺陷、軟件結(jié)構(gòu)缺省、數(shù)據(jù)缺陷、軟件實現(xiàn)和編碼缺陷、軟硬件接口缺陷等。其中靜態(tài)缺陷可以比較容易克服,比如嚴格的質(zhì)量過程;但動態(tài)缺陷往往比較難于發(fā)現(xiàn),比如可能隨機產(chǎn)生的某個事件引起程序執(zhí)行中的時序錯誤。因此在風險分析進行到設(shè)計過程時應(yīng)適當運用如時序分析、事件分析、Petri網(wǎng)分析等工具。
下面列出一些對前面給出的“以行車調(diào)度為核心的綜合監(jiān)控系統(tǒng)架構(gòu)模型”的實施建議。
(1)人工操作與自動控制命令互鎖
融合了ATS基本監(jiān)控能力的綜合監(jiān)控軟件平臺與原來相比,需要增加一個至關(guān)重要的功能,即人工控制命令與自動控制命令互鎖,適用于任何列車和信號系統(tǒng)設(shè)備,以確保:
①受ATS基本監(jiān)控影響的所有操作員請求的控制優(yōu)先級都比 ATS應(yīng)用程序的自動命令優(yōu)先級高;
②所有操作員控制請求都被直接發(fā)送給現(xiàn)場,并遮蔽ATS應(yīng)用程序產(chǎn)生的現(xiàn)場命令;
③所有ATS應(yīng)用程序產(chǎn)生的命令都不能遮蔽操作員命令。
(2)關(guān)鍵控制操作
對于安全相關(guān)的控制功能,要求操作員必須介入,實行類似如下步驟的“執(zhí)行前檢查”過程,并且用戶輸入一個控制命令要服從特定的時間約束。
①操作員選擇執(zhí)行一個命令;
②命令發(fā)送到執(zhí)行裝置;
③執(zhí)行裝置驗證控制狀態(tài);
④執(zhí)行裝置將檢查結(jié)果返回給控制系統(tǒng);
⑤控制系統(tǒng)將檢查結(jié)果顯示給操作員請求證實(Confirm);
⑥控制系統(tǒng)將證實發(fā)送到執(zhí)行裝置;
⑦執(zhí)行裝置執(zhí)行該命令;
⑧控制系統(tǒng)驗證返回條件。
(3)設(shè)定值
設(shè)定值用于改變底層裝置中的模擬量設(shè)定值,或綜合監(jiān)控數(shù)據(jù)平臺本身實時數(shù)據(jù)庫中的某些狀態(tài)值,比如設(shè)備或區(qū)域的維修掛牌。設(shè)定值應(yīng)在計算機切換或掉電恢復(fù)后依舊保持。
(4)連接和會話
考慮到增強信息技術(shù)安全對性能的影響,對于安全相關(guān)的關(guān)鍵控制,如設(shè)置/解除臨時限速,應(yīng)采用與普通數(shù)據(jù)傳輸不同的獨立的OPC UA安全通道和會話,并采用單獨的加密算法。
(5)并行發(fā)送
當安全相關(guān)命令有強烈的限時到達要求,且并行發(fā)送對底層信號系統(tǒng)無害時(即可以處理相同命令的兩次發(fā)送),則可以采用冗余雙網(wǎng)并行發(fā)送控制命令,以解決EN50129-2指出的消息延時這一基本消息錯誤。
以行車調(diào)度為核心的城市軌道交通綜合監(jiān)控系統(tǒng)是一個牽涉到多種技術(shù)領(lǐng)域,由多種設(shè)備、多種硬軟件、多種設(shè)施組成的復(fù)雜系統(tǒng),真正實施時還要面臨綜合監(jiān)控廠家和信號廠家密切協(xié)作的問題。在安全性、可靠性方面,最關(guān)鍵的是保證兩點:第一,不引起或不提供虛假輸出,包括向現(xiàn)場輸出和向用戶界面輸出;第二,當操作員想要執(zhí)行一個安全相關(guān)操作時,系統(tǒng)處于可用的狀態(tài)。當然,在開放的網(wǎng)絡(luò)環(huán)境又引入了信息技術(shù)安全的問題,對此采用的 OPC UA協(xié)議標準幾乎是一個“開箱即用”的解決方案。
[1]周庭梁,孫軍峰,孫春榮.談以行車指揮為核心的城軌交通綜合監(jiān)控系統(tǒng)[J].現(xiàn)代城市軌道交通,2009(3):14-17.
[2]郭永泉.城市軌道交通綜合監(jiān)控系統(tǒng)集成信號 ATS的研究[J].現(xiàn)代城市軌道交通,2008(6):34-36.
[3]魏祥斌.集成信號列車自動監(jiān)控子系統(tǒng)的綜合監(jiān)控系統(tǒng)方案[J].現(xiàn)代城市軌道交通,2012(8):86-89.
[4]趙惠祥,余世昌.城市軌道交通系統(tǒng)的安全性與可靠性[J].城市軌道交通研究,2006(1):7-10.
[5]CEI IEC61508:Functional safety of electrical/electronic/programmable electronic safety-related systems(Version 12.0)[S]. 1997.
[6]德國工業(yè)4.0工作組.把握德國制造業(yè)的未來實施“工業(yè) 4.0”攻略的建議 [M/OL].[2013-09-xx](2014-10-07).http://doc.mbalib.com/view/3a447da3247684d8c66bc5e 9b35567a9.html.
[7]CENELEC prEN50126:Railway applications—The specification and demonstration of Reliability,Availability,Maintainability and Safety(RAMS)[S].1999.
[8]CENELEC prEN50159-2:Railway applications-communication,signalling and processing systems-Part 2:Safety related communication in open transmission systems[S].2001. [9]IEEE Std 1474.1:EEE Standard for Communications-Based Train Control(CBTC)Performance and Functional Requirements[S].1999.
[10]OPC Unified Architecture Specification Part 2:Security Model Release 1.02[S].2013-04-17.
Safety and security research for integrated supervisory control system with traffic control as the core in the open network environment
Xie Hongbing
(Beijing Hollysys System Engineering Co.,Ltd.,Beijing 100176,China)
This paper discusses the safety and security problems for integrated supervisory control system with traffic control as the core in the open network environment at the urban rail traffic.Thefocuses of attention areidentified,and a concrete implementation scheme based on OPC UA is proposed.Finally,some implementation suggestions are put forward.
integrated supervisory control system;signal system;ATS(Automatic Train Supervision);open network environment;safety;reliability;OPC Unified Architecture
TP29
A
1674-7720(2015)02-0001-06
北京市科學(xué)技術(shù)委員《以行車指揮為核心的軌道交通智能運營自動化系統(tǒng)研究及示范應(yīng)用》(2012)
(2014-11-07)
謝紅兵(1962-),男,本科,研究員,主要研究方向:工業(yè)自動化系統(tǒng)軟件。