摘 要： 探讨了在城市轨道交通综合自动化系统中将传统以电调、环调为核心的综合监控系统与信号系统中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.