基于云架构的城市轨道交通信号系统方案研究

郭弘倩，南 迪

（1.国家知识产权局专利局专利审查协作天津中心，天津 300304；2.中国铁路设计集团有限公司，天津 300308）

随着国内对“互联网+城市轨道交通”战略的推进，云计算、大数据等信息技术已逐渐成为轨道交通发展的趋势。城市轨道交通由运营生产中心、企业管理中心和乘客服务管理中心组成，建立一个涵盖安全生产、内部管理和外部服务等多领域的大数据平台，也是当前智慧城轨系统的需求。

传统城市轨道交通安全生产业务采用基于传统物理服务器分散隔离式部署模式建设，造成硬件资源利用率严重不平衡。随着各地城市轨道交通线网快速发展，业务系统分散部署和物理隔离的模式已逐渐无法满足资源集中管理，高密度数据交换等深层次的资源、数据共享需求。

采用云架构建设城市轨道交通信息化系统，构建服务器、存储、网络等资源池，通过对城轨业务系统之间的横向融合和各线路间信息资源的纵向融合，最终可实现城市轨道交通的全方面融合、全方面的资源共享。

1 当前技术发展现状

信号系统作为安全生产网的重要组成，也是保证城市轨道交通行车安全的基石。信号系统主要由列车自动防护（Automatic Train Protection，ATP） 、列车自动运行（Automatic Train Operation，ATO）、 列车自动监控（Automatic Train Supervision，ATS）和联锁4个子系统组成，共同完成列车自动控制功能。考虑系统功能定位和设备选型，ATS子系统具备纳入云平台条件。

根据功能定位，ATS系统应设置于IaaS层，即可任意部署和利用云平台的处理、存储、网络等计算资源部署与运行操作系统和应用程序等各种软件，但不可操作云平台管理系统，保证云平台上各安全生产业务系统的相对独立性和安全性。

ATS主要实现线路/线网的运营监控，运行图和列车时刻表编辑和根据计划组织全线路/线网的统一调度，同时可向PIS、ISCS、PA等系统传输列车运行信息。相较于传统“信息孤岛”模式的系统架构，ATS子系统可利用云平台实现安全生产数据交换，同时借助大数据平台为内部管理网和外部服务网提供一些有用信息如列车正晚点信息、列车时刻表、运营数据等，对于城轨的建设者、运营者和使用者均有创新意义。

2 云平台部署原则

ATS纳入城轨云平台时，既需要考虑ATS系统与其他业务系统实现效率最大化的信息交换共享，又必须保证信号系统对安全性的要求。本节结合信号ATS子系统与云平台接口的设计要求及传统ATS子系统部署原则进行分析。

2.1 ATS子系统与信号安全系统的接口设备

信号系统网关计算机，作为ATS子系统与信号安全系统的接口设备，实现ATS子系统逻辑数据与信号安全系统逻辑的交互，为保证云平台与信号安全系统的隔离需求，ATS子系统网关计算机不纳入云平台部署及管理。

2.2 ATS子系统与非信号专业接口设备

云平台建设过程中，多专业共用云平台可最大限度地实现云平台的资源利用率。由于各个专业均纳入云平台部署及管理，ATS子系统与非信号专业的接口设备可纳入云平台部署及管理。

2.3 ATS子系统车站设备

ATS子系统车站设备主要包括现地控制工作站和ATS车站分机。结合考虑中心故障后，保留车站降级模式功能的设计需求进行分析：在控制中心故障后，ATS子系统优先使用站控模式进行运营组织，ATS车站分机借助现地工作站实现中心故障后站控模式的运营能力。由于部分厂家采用非通用服务器/工作站的方式部署ATS分机，暂不建议将其纳入云平台部署。当中心ATS系统、车站分机均故障时，现地控制工作站作为联锁控显机（上位机）直接对联锁主机进行控制命令输出，因此也不建议将现地控制工作站纳入云平台管理。

2.4 ATS系统网络

纳入云平台后，中心级ATS系统网络需纳入云平台，车站级网络可纳入云平台也可采用自组网方案。当采用自组网方案时，车站ATS独立组建光纤环网，在中心通过安全隔离设备（如网关）接入云平台网络。

3 系统架构分析

按照国内武汉、呼和浩特等在建或已开通的城轨项目经验，目前信号ATS系统纳入云平台主要思路是“中心上云，车站不上云”，即中心ATS系统纳入云平台，而车站联锁、ATP/ATO及站级ATS系统保留传统架构。

云平台对CPU的调度是以逻辑核为单位的，逻辑核是将物理核通过超线程（HT）技术模拟成2个逻辑核心，每台计算节点服务器承载vCPU数量计算方法如下：vCPU数量＝（CPU数量×每颗CPU物理核数量×2－虚拟化层占用逻辑核数量）×虚拟化复用比。

虚拟化复用比是一台服务器上虚拟机的vCPU的总数相对可用逻辑核数（不包括虚拟化层占用逻辑核）数量的比率，标称的是服务器上逻辑核复用的程度，一般情况下推荐复用比为1.0，不同应用场景下复用比推荐如表1所示。

表1 虚拟机应用场景对照Tab.1 Comparison between the application scenarios of virtual machines

以一条标准线路为例，对系统配置进行分析，系统配置如表2所示。

表2 系统配置示意Tab.2 Example of system conf iguration

3.1 云平台硬件选型

目前城轨云平台处于发展的起步阶段，仍以硬件云为主，存储资源主要由整合服务器搭建完成。目前云平台常用的服务器主要有：刀扇式服务器、机架式服务器以及上述2种服务器组合的形式。

方案1：业务服务器&数据库服务器全部采用刀片；

方案2：业务服务器&数据库服务器全部采用机架；

方案3：业务服务器采用刀片，数据库服务器采用机架。

刀片式服务器与机架式服务器面对不同场景、需求，各有优势。在城轨云平台的体系下，考虑到多种业务的硬件融合，刀片式服务器的高密度分布和计算能力更适合业务服务器，而数据库服务器本身用于存储的是本专业的重要运营数据，考虑使用机架式服务器作为选择。综上，ATS系统推荐采用方案3：应用服务器及接口服务器采用刀扇式服务器，数据库服务器推荐采用机架式服务器。

3.2 计算资源架构

计算资源包括服务器（应用服务器、数据库服务器、接口服务器）、工作站（调度员/调度长工作站、时刻表/运行图编辑工作站、维护工作站）。

中心级服务器硬件（应用/接口服务器采用云主机，云管从虚拟资源池统一分配计算资源，数据库服务器考虑信号系统特殊性采用裸金属服务器）纳入云平台管理，软件由ATS系统提供，保留ATS系统既有架构不变。虽然云平台本身具有冗余和备份功能，但不能满足ATS系统主/备无扰切换需求，因此ATS系统切换逻辑由主/备双套的ATS系统软件完成。此外，云平台还可以为同一专业多条线路的数据库服务器提供共享存储空间，提高服务器利用率。

培训系统相关设备一般仅在培训时开机，可以考虑将其纳入云平台，使用时通过云管为其分配相应的虚拟机分区即可。也可以保留其全套硬件，作为信号系统初期调试的备份系统使用。

根据线路情况，ATS系统业务资源配置推荐如表3所示。

表3 计算资源池资源需求Tab.3 Resource requirements of the computing resource pool

其中虚拟机损耗为5%，虚拟化复用比采用1.5。另外，考虑业务高可靠（HA），根据经验，需要预留30%资源支撑HA。按照上述业务资源需求及计算公式，具体物理服务器资源如表4所示。

表4 计算资源池服务器配置Tab.4 The conf iguration of servers of the computing resource pool

行调工作站、时刻表编辑工作站纳入云平台，可纳入桌面云系统直接管理，也可参照服务器上云方案仅硬件上云，在云主机提供的虚拟机中安装相关软件。需要注意的是，由于上述工作站直接参与列车调度信息交互，上云时应考虑云平台安全完善度等级与ATS系统保持一致，即满足SIL2级安全完善度等级的要求。由于维护网与车站级设备共同接入维护网，不建议中心ATS维护终端上云。ATS系统云桌面资源配置推荐如表5所示。

表5 计算资源池云桌面需求Tab.5 Cloud Desktop requirements of the computing resource pool

考虑到工作站数量较少、硬件要求较低，为实现资源云化、整合硬件数量的需求，因此配置服务器时，一般采用多个专业工作站计算资源共同整合的模式。根据经验，在考虑虚拟机损耗、虚拟化复用比按1.5设置的情况下，一台云主机可同时承担90个vCPU的计算能力。

3.3 存储资源架构

存储资源主要包括服务器/工作站自身存储和运营数据存储，业务存储资源采用FC SAN架构，各业务服务器双归属到两台FC交换机，FC交换机分别与存储设备互联，架构如图1所示。

图1 城轨云平台存储架构示意Fig.1 Storage architecture of the urban rail cloud platform

3.4 网络资源架构

如图2所示，ATS系统通过云平台接入交换机和云平台核心网交换机实现与本系统及其他系统的信息传输及交换。为简化网络部署，提高网络可靠性，多台接入交换机采用堆叠技术虚拟化为1台。

图2 城轨云平台网络架构示意Fig.2 Network architecture of the urban rail cloud platform

为保证ATS业务带宽，推荐每台接入交换机采用10 G链路聚合与核心交换机互联。

3.5 信息安全防护

《网络安全等级保护测评要求 第2部分：云计算安全扩展要求》中明确提出：在云计算环境中，应将云服务方侧的云计算平台单独作为定级对象定级，云租户侧的等级保护对象也应作为单独的定级对象定级。

云计算安全要求应涵盖物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全、安全建设管理和安全运维管理等内容。

基于上述准则，在本方案中，云平台作为单独的定级对象，由云平台厂商提供等级保护技术建设及等级保护测评服务；ATS系统作为单独的定级对象，由专业安全厂商提供等级保护安全建设及等级保护测评服务。

目前城轨云平台还是以硬件云为主，控制中心云平台通过设置核心交换区来实现中心各业务系统之间的数据交换。为保证信息安全，在核心交换区的交换机上可以旁挂防火墙和入侵检测等设备。中心级ATS系统纳入云平台后，ATS系统与其他系统接口由硬件网络接口变为逻辑接口，ATS系统内部架构保持不变，站段级ATS系统通过接入交换机接入中心级ATS系统。

信号系统和云平台均应按照信息安全等级保护三级进行建设。

4 工程建设中需注意的问题

本文分析了ATS上云方案，但对于信号ATS系统是否上云目前还处于百家争鸣阶段，各类工程建设规范也并没有强制性要求ATS系统纳入云平台。在实际工程运用时，不论是建设单位、运营单位还是设计单位，应结合不同线路规划及投资情况考虑云平台整体架构是否有必要将ATS系统纳入云平台，同时也应知晓ATS上云后，相比传统架构需额外注意如下的问题。

1）ATS系统属于信号系统的核心组成部分，一旦控制中心因火灾、地震等灾害中断势必导致行车中断，考虑极端场景下云平台宕机场景，根据线路重要程度可考虑设置灾备中心以应对主用中心瘫痪时信号行车调度指挥的可用性和功能完整性，并做好应急预案。

2）上云后，ATS系统需通过云平台网络接入中心级ATS系统，在信息安全方面云平台必须整体实现三级防护。

3）ATS采用冗余机制，可实现主/备系统的无扰切换。目前云平台虚拟机间的热迁移功能（HA）因需要在主资源池故障时重新启动一套同配置的虚拟机，不具备无扰切换能力，因此ATS主/备系统需同时分别占用云资源，并由信号系统软件自行判断切换时机。

5 总结与展望

国内的轨道交通业自20世纪80年代开始孕育，随着线路长度、机车数量、客运数量等指标不断攀升，现己成为世界最大的城市轨道交通建设市场。在不断增长与建设的背景下，轨道交通作为城市交通的重要组成部分，其智能化是智慧城市、智慧交通的重要组成。在《国家中长期科学和技术发展规划纲要(2006-2020年)》中指明，“高速轨道交通系统”和“智能交通系统”是优先主题。轨道交通智能化系统是以多系统为基础的综合平台，是现代轨道交通发展的必然趋势。《智慧城轨发展纲要》也提出：建设一个自主可控、功能完备、技术领先、安全可靠、可持续发展的城轨云与大数据平台，实现对城轨业务应用的统一部署承载，资源动态分配，统一开发运营部署运行环境，为城市轨道交通各类信息系统应用提供服务，助力城轨智能化、智慧化发展。信号系统作为涉及行车安全的重要系统，系统运行数据是作为现在轨道交通大数据平台的重要组成部分。信号ATS系统作为列车行车调度指挥的“大脑”，存储着大量线网列车运营数据，对于将其融合到线网大数据云平台，为实现城轨智能化、智慧化有着非常重要的意义。