列车自动监控系统主备中心设计分析

导语：列车自动监控系统主备中心设计分析一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

摘要：呼和浩特城市轨道交通工程首次采用了云平台统一承载，实现了列车自动监控系统在云平台上的集成运行。为了确保信号系统入云后，整个系统运行的稳定性和可靠性，设计部署主备控制中心。结合呼市列车自动监控系统主备控制中心的建设要求，分析云平台上相关的设计需求；提出了一套基于云平台的主备控制中心的切换方案，并设计了云平台主备控制中心之间、中心与云外设备之间的数据流向分析。研究完成了主备中心相关功能的实现以及在云平台上的项目应用部署，解决了业务系统转为云平台部署后所带来问题，为其他轨道交通主备中心云平台建设提供参考。

关键字：云平台；信号系统；主用中心(MOCC)；备用中心(BOCC)；列车自动监控系统（ATS）

呼和浩特城市轨道交通工程是城轨交通云平台的试点项目，云平台作为一个集中式的硬件管理和资源动态分配平台，上面部署了列车自动监控系统（AutomaticTrainSupervision,ATS）、综合监控系统(IntegratedSupervisoryControlSystem，ISCS)、乘客向导系统（PassengerInformationSystem,PIS）等一系列生产业务系统，以及企业的办公管理系统(OfficeAutomation，OA)。云平台一旦发生故障，将会对众多业务产生影响。其中ATS系统是最为关键的行车指挥系统[1]，一旦其出现故障，整个控制中心将无法执行相应功能，因此异地设置一套独立运行的备用中心十分必要。同时，云平台依赖网络[2]，存在时延和网络信息安全保护不足的问题。因此传统的ATS系统设计方案不能简单地平移部署到云平台，需要结合云平台的特点，探讨相关部署要求，并对原有系统的功能进行设计调整。本文对整个系统主用中心与异地备用中心（简称“主备中心”）的功能需求、系统架构和功能实现等方面进行分析与研究。

1需求分析与功能设计

一般来说，主用中心是轨道交通调度员日常工作的主要场所，备用中心不会频繁使用，故备用中心的云平台资源配置可以作简化处理，基于此进行主备中心需求分析。首先考虑选址问题，主备中心的选址不仅要防范各种可能的风险、满足云平台机房的建设条件，还要考虑建设成本，交通的便捷性和专业保障等多个因素，以确保主备中心的选址科学合理。其次，实际业务需求是本次研究的核心，涉及使用、维护和可靠性等多个方面，主要包括：

1）灾备需求。一旦主用中心遇到地震、火灾等特殊情况，无法继续履行工作职能时，应立即启用备用中心执行监控任务，确保运营的连续性。

2）运维需求。当主用中心云平台需要进行短期整体性维护时，主用中心的工作人员应借助于本地工作终端和备用中心的中央服务器，继续履行相应职责。为了保证两个中心可快速平滑切换，并具备实时监控的条件，通过对ATS系统自身功能和数据结构的梳理，细化出以下五点功能。

1.1现场设备监控

主备中心应同时具备实时监视功能，不仅要对线路的列车、轨旁联锁设备、轨旁列控设备的运行状态进行监视[3]，也要对整个ATS系统自身设备运行状态进行监视。在控制操作上，因为指挥权的专一性要求，只有唯一的中心可以执行行车调度控制功能，所以要避免主备中心同时指挥，以确保最终责任的界定。

1.2统一设备维护

主备中心异地建设，按照传统设置，需要引入两个维护团队，会带来较大的人力成本。转到云平台部署后，维护团队新增了云平台管理维护功能，相应的维护工作内容也会进一步增加。为降低维护团队的工作强度和工作压力：主备中心需要具备简洁的维护管理功能，借助于统一界面，实现对两个中心设备的远程维护；有了云平台后，对于个别设备故障，维护人员可以借助于云平台技术对设备进行远程修复或者虚拟资源重新分配，大幅缩短故障修复时间。相对于传统主备中心设置，可维护性得到更好的提升。

1.3运行数据同步

ATS系统包含两部分数据：一部分是现场设备状态的数据，两个中心可以实时获取，无需两个服务器之间进行同步；另一部分是主用中心才会产生的列车运行基础数据，如：用户管理、计划运行和列车出入库数据等。主用中心服务器需要在这些数据产生后，自动同步给备用中心服务器。数据同步速度必须实时，控制在秒级；数据内容也必须正确完整，在同步的过程中需要增加相关的完整性检查。两边服务器的实时正确同步才能确保两个中心业务切换的连续，对在线列车的运行不产生任何影响。

1.4主备中心切换

1)单一中心设备的自动切换。ATS系统是一个实时监控系统，一旦出现中央服务器的宕机，就可能导致列车无法继续运行。因此，对单一中心的中央服务器都采用了硬件独立的双机冗余部署，按照主机和备机的运行模式进行设计：备机自动监测主机的运行状态，一旦主机出现宕机或设备工作异常，备机自动升级为主机，替代主机执行监控功能。

2）主备中心设备的人工切换。当主用中心发生云平台故障或者ATS系统中央服务器双机宕机故障时，控制权就需要切换到备用中心，启用备用中心的行车监控功能，切换分两种情况：一种是主用中心完全无法工作，需要备用中心的人员激活列车监控功能，在备用控制中心进行相应作业；另一种就是主用中心的工作终端和网络还是可以与备用中心保持正常工作，这种场景下，主用中心的工作终端就可以切换连接到备用中心设备上，激活备用中心控制功能，进行指挥作业。这两种场景的切换任何时刻都可能发生，切换前后两个中心的状态需要保持一致，切换时间需要控制在秒级，切换操作对在线运营的列车正常运行不能产生任何影响。

1.5工作终端交互

为满足主备中心的设备互为备用的需求，工作终端需要同时连接主备中心服务器：正常情况下，主用中心的工作终端用于行车调度指挥，备用中心的工作终端用于在线培训或在线维护。当主用中心发生故障情况下，主用中心的工作终端可以切换使用备用中心的中央服务器，继续进行行车调度指挥。也可以直接安排人员启用备用中心的工作终端进行行车调度指挥。

2选址设计

呼和浩特运营控制指挥中心是集中设计的基于云平台的中心[4]，该中心在设计之初就预留了接入整个城市多条轨道交通线路的容量。借助于云平台强大的可扩展能力，为后续多个线路的接入提前打好基础。主用中心新建了调度指挥中心大楼，并设计了统一的机房，充分满足了主用中心云平台统一机房的建设要求。在备用中心选择方面：首先，由于备用中心属于非常用操作地点，考虑建设成本的因素下，其设备可以减配。尽管无需主用中心同样面积的机房，但也需要充分考虑《GB50174-2017数据中心设计规范》云平台机房建设的相关要求，能够支撑备用中心云平台的建设；其次，备用中心与主用中心在地理位置上需要相距一定距离，确保两者之间满足灾备要求；最后，需考虑两个中心的专业支持保障能力，便于工作人员和技术保障人员快速到达。对既有轨道交通线路所有的场所考察后，设计了以下评估因素：建设成本尽量低、建筑空间支持云平台机房设备部署、物理地址距离主用中心10公里以上、网络建设与既有线路网络贯通便捷和工作人员出入交通方便。基于这些因素，借助层次分析法[5]最终评价得出1号线车辆段是轨道公司既有资产，运营成本较低；有足够的建筑空间,与主用中心地址距离20公里，满足灾备需求，也可防护外部其他故障；同时该地点也与1号线和2号线相邻，便于云平台网络快速实现与2号线网络互通；车辆段具备专业的技术保障人员，紧急情况需要调配其他专业人员到备用中心工作，也可统一安排通行，确保运营快速恢复[6]；最终确定在呼和浩特轨道交通1号线车辆段建设2号线的备用中心。

3主备中心设计

3.1方案比选

控制中心设备部署主要包含工作终端部署和中央服务器部署两个方面。首先，在工作人员的工作终端部署方面，尽管云平台可以完成工作终端设备的虚拟化，也可以提供一套性能简单的操作终端，简称瘦客户端，其通过云平台网络和专用远程桌面协议完成与云平台内部虚拟机交互。因为工作终端包含了安全相关的功能操作，瘦客户端的这种交互方式无法证明相关操控的安全性，故工作终端只能按照传统定制化选型硬件进行部署。其次，在中央服务器部署方面，存在以云平台技术为核心和以ATS系统技术为核心的两种方案。方案1：借助于云平台技术的动态分配资源和资源热迁移特性来实现主备中心功能[7]。当云平台的内部网络或者计算资源发生硬件故障后，云平台管理系统实现了故障检测和资源重新调度的功能，将当前虚拟机计算需求调整到其他硬件资源进行计算，从而提高整体设备运行的可靠性。云平台支持热备份，即对在线的虚拟机相关资源进行在线备份。这些备份的虚拟机资源，在云平台主用中心发生严重故障后，借助于维护人员的操作，可以将主用中心备份的虚拟机资源迁移到备用中心云平台中[8]（简称“热迁移”），重新启动运行，也可实现主用中心的功能。经过分析，这种方案存在以下不足：

1）需要花费较长的时间才能够识别设备故障，实时性不高；

2）在对虚拟机资源进行热备份时，云平台无法深入到每个业务系统的内部，只能将整个虚拟机资源的数据整体复制，浪费资源的同时也需要较长的时间；

3）云平台对备份的虚拟机资源热迁移后再次运行时，系统启动后会含有部分滞后的信息，可能会给现场在线运行列车发送错误的命令。需要维护人员进一步检查切换后的设备运行状态，才能投入运营。方案2：借助于业务层的主备同步方案[9]，配合云平台进行兼容性适配。传统的设备配置方案包括应用服务器，通信前置机和数据库服务器等独立的物理设备。转为云平台后，服务器需要运行在云平台计算单元中，见图1。主用控制中心云平台计算单元借助于云平台的硬件资源部署了冗余服务器，构建了ATS系统强大的后台计算单元，保障信号系统实时信息收集、计算、分发和存档等工作。同时禁用云平台动态分配硬件资源的特性，借助于云平台资源管理系统，强制将各种服务器分别放在不同的硬件实体上，确保一旦发生单个服务器主机故障或者业务系统自身缺陷导致业务软件宕机后，业务层能快速感知[10]，无缝切换到物理差异的备用服务器，可解决主用中心各个服务器双机运行的可靠性问题。考虑到备用中心属于临时阶段性的使用单元，因此备用控制中心云平台计算单元采用了单机简化配置的方式，满足备用中心可临时接管整条线路行车指挥的条件。备用中心与主用中心云平台保持相互独立运行，这种方案保留了传统方案主备切换的实时性要求，同时利用了云平台设备维护的便捷性。缺点是浪费了云平台既有的资源动态分配的灵活性，也增加了对云平台资源的消耗。比选上述方案，方案1节省资源，但ATS系统对实时性要求较高，无法使用。方案2虽然浪费了部分资源，但是满足ATS系统的业务需求。因此，呼和浩特轨道交通2号线的主备中心设计采用方案2设计，通过ATS系统业务自身适配云平台技术实现主备中心，确保两个中心的可用性、实时性和可维护性。

3.2切换设计

主备中心设计的核心逻辑是实现两个中心之间的无扰切换，包含服务器与工作终端的切换和服务器之间的信息同步两个方面。应用服务器设计上，主用中心与备用中心需要实现同样的功能，备用中心保持与主用中心状态同步运行:主用中心各服务器双机以“主机-备机”方式运行；备用中心各服务器单机以“主机”的方式运行。这种主备中心同时以主机运行的方式属于双活设计，都具备对在线列车进行监控的功能；但为了明确两个中心的指挥权：同一时刻只能有一个中心对全线设备发出控制指令。主备中心业务层面设计了“主用”状态，任何中心只有在获得“主用”状态后，相应的控制指令才可以下发给现场设备。传统ATS系统主备中心切换方案是主机和备机的切换设计：一个中心的主机故障后，自动切换到备机；一主用中心双机故障后，自动切换到备用中心服务器。这种设计经常会出现无必要的主备中心控制权自动倒切，也容易产生错误的数据同步。比如：在周期性检修时，维护人员对主用中心双机设备进行重启操作后，备用中心将会自动升级代替主用中心。检修完成后，维护人员需要操控备用中心设备，将控制权切换回主用中心。本方案中，工作人员在对主用中心设备双机重启后，在没有人工授权操作情况下，备用中心不会自动获得控制权,工作终端自动切换连接到备用中心，提供全线监视功能。等主用中心检修完毕后，工作人员激活主用中心的控制权，工作终端又自动切换连接到主用中心。所有的检修工作均在主用中心完成，无需再对备用中心设备进行操作。为了实现无扰切换，主备中心的应用服务器之间更需要保证双机状态的实时可靠同步。对于实时信息，主要是轨旁各种设备的状态，包括列控设备、联锁设备、车载设备以及ATS系统设备状态，由车站设备采集后同时发给主备中心的服务器。这样主备中心的服务器就能实时获取相应的信息，无需再在服务器之间进行同步；对于非实时信息，如用户、系统参数、时刻表和出入库计划等信息，只能在具备“主用”授权的服务器上创建，然后借助于高可靠的数据同步协议，同步给另一个服务器。通过这种深入业务系统内部分类的信息同步，从而在有限的带宽资源基础上，在控制权切换后，完成两个中心之间实时和可靠的信息同步，实现两者之间无扰平滑过渡。

4方案实现

4.1系统架构

呼和浩特2号线的ATS系统是一个横跨传统车站信号设备、云平台计算中心和主用中心控制大厅/车辆段灾备控制中心的三层架构，见图2。

1）车站信号设备作为现场终端节点，采集现场列控设备的状态和发出控制指令。主要包括车站服务器、车站现地工作站、网关服务器和车站网络设备等，其中车站服务器和网关服务器是其中最关键的节点，这些设备等同于云平台的边设备，计算功能比较单一。2）云平台计算中心包括主用控制中心和备用控制中心两个独立的控制中心：主用控制中心的云平台虚拟机中包括双套的应用服务器，通信前置机和数据库服务器；备用控制中心的设备包括单套的应用服务器，通信前置机和数据库服务器。这两个控制中心是ATS系统的大脑，负责实时状态信息和行车计划调整计算；。

3）主用中心控制大厅和车辆段灾备控制大厅的工作终端设备主要是辅助中心云计算节点，提供人机交互操作。在主用中心控制大厅包括多套工作终端，分别用作调度主任工作站、调度工作站和维护工作站等；在车辆段灾备控制中心也部署了少数工作终端，分别用作调度主任工作站、调度工作站和维护工作站等；在这些工作终端中，调度工作站是最关键的设备，确保ATS系统安全操作的安全性。

4.2整体数据流实现

ATS系统数据流交互包括纵向和横向数据流。在纵向交互方面，包含自下而上的状态数据和自上而下的运行控制数据；在横向交互方面，主要是各个区域内各设备之间的数据交互。

1）纵向自下而上数据流：车站的信号设备一直与联锁设备、轨旁列控设备和车载设备进行信息交互，实时获取当前线路的计轴、道岔、信号机、屏蔽门、轨旁列控、车载和车辆等一系列设备的状态信息。这些信息同步发送给主备中心的应用服务器，进行缓存和记录，并同步给当前连接的终端，提供在线监视服务。

2）纵向自上而下数据流：工作人员需要对现场设备进行控制，或者调整当前列车的运行计划等，这些指令会由工作终端发给连接的应用服务器，经过合法性检查后，在当前应用服务器内部执行或下发给对应设备所在的车站服务器执行。执行结果，由执行单元借助高可靠的数据通信协议同步发给备用的应用服务器，完成相应的信息同步。如：有授权的主用中心应用服务器接收到创建当天时刻表指令后，会完成新的当日时刻表创建，并同步发给备用中心应用服务器，创建相同的当日时刻表。一旦发生两个中心之间的切换时，因为其内部信息一致，实时处理产生的结果会保持一致，则不会影响现场设备的运行。

3）横向数据流：车站服务器执行关键信息的处理，也负责与车站联锁设备接口；网关计算机负责与轨旁列控设备接口，将获取的信息经过预处理后发给车站服务器，车站服务器汇合联锁设备数据和列控设备数据，统一处理后，发给车站现地工作站和主备中心的应用服务器。在主备中心云平台中，数据库服务器负责现场历史数据和各种时刻表信息的存储；通信前置机负责实现ATS系统与其他业务系统之间数据交互，如综合监控，乘客向导等系统交换列车运行、计划信息等；应用服务器是控制中心的核心，从数据库服务器存取各种数据，配合通信前置机完成与其他业务系统的信息交互，最为关键的就是完成与工作站终端之间的数据交互。数据之间的交互包含云平台内外数据的交互，也包含不同业务系统之间的交互。这些数据交互需要满足信息安全等级保护的要求：主备中心云平台内部，在通信前置机对外接口上部署云内防火墙[11]，实现ATS系统业务与其他系统业务之间数据交互，满足云内不同业务系统之间信息安全的要求；云内与云外设备之间数据交互，主要是云内的应用服务器与云外的工作终端和车站设备之间的数据交互。云平台接口交换机和ATS系统云外交换机之间需要各自部署硬件防火墙实现云内外的信息安全隔离。

4.3主备中心切换

主备中心切换实现包含双机自动切换和主备中心授权切换。双机自动切换在主用中心内部进行。主用中心内部配备了两台功能相同各自独立运行的服务器，如应用服务器A机和应用服务器B机，一台作为主机运行，一台作为备机运行。这两个设备之间采用设备健康度诊断的方法：备机实时监控主机设备的运行状态，周期性交换两台服务器的健康度诊断结果。当备机发现主机设备故障或者健康度出现降级时，备机自动通知主机退出，同时将自己升级为主机，接管线路运行，保障ATS系统可靠运行。主备中心授权切换是主备中心之间的控制权切换，采用人工授权的方式。根据既有轨道交通调度管理规则，线路的控制同一个时刻只能被一个中心管理[12]。因此，在主备中心“主用”授权转换功能逻辑见图3。系统初始化时，授权令牌处于无授权状态；主用中心工作人员通过图4工作终端授权交互界面进行操作；发出授权指令后，两个中心的应用服务器会进行交互检查，在确认满足唯一性控制要求后，正式给予授权。同时，工作终端的主备中心图标将会显示授权状态，便于调度和维护人员清晰了解当前授权中心。若此时备用中心人员也尝试操作授权该令牌，则返回错误；若备用中心需要获取授权，则必须在主用中心释放该授权令牌后，才可以人工申请。除人工操作之外，主备中心也会实时监控该令牌授权的持续有效性，避免一个中心的应用服务器双机宕机后，授权令牌无法释放，进而进入死锁状态。当这种双机宕机场景发生时，授权令牌在一定周期超时后，系统自动复位到初始无授权状态，等待人工操作授权。

5总结

该主备中心设计方案一方面保留了传统主备中心设计的实时性和可靠性，实现了主备中心在云平台上的稳定运行以及相互之间的无扰切换；另一方面，借助于云平台的虚拟化技术，进一步提升了主备中心设备的可维护性，使得设备远程维护管理方式更加便捷，借助于云平台瘦客户端即可完成ATS系统设备的资源巡检，远程重启和重新部署等一系列的工作，不仅节省了人力，也极大降低了维护成本和工作量。目前该方案已在呼和浩特2号线ATS系统中完成部署，经过一年多的现场实际运行和主备中心倒切测试，充分证明了整个方案设计的合理性和稳定性。在2号线实际运营过程中，仅发生过一次主用中心数据库故障，调度员及时切换到备用中心，继续开展行车调度工作，实现了设备迁移，但人员工位保持不变的效果，进一步验证了本方案可行性，后续将进一步推广到其他轨道交通项目中。

参考文献

[1]周公建,满化录.北京市轨道交通亦庄线ATS子系统设计[J].市政技术,2010(S2):366-370.

[2]黄龙,张博.城市轨道交通云平台建设方案分析[J].铁道通信信号,2020,56(9):76-80.

[3]孙梦剑.浅谈地铁无人驾驶线路主、备控制中心的设置[J].建筑工程技术与设计,2018(24):3511.

[4]吕梅新.浅谈云灾备管理平台建设[J].信息技术与信息化,2021(3):53-55.

[5]骆成蹊.使用层次分析法(AHP)解决异地灾备数据中心选址问题[J].现代电视技术,2022(9):110-114.

[6]齐麟.地铁清分中心灾备系统设计的几点建议[J].科技风,2018(10):195.

[7]陈晓,张龙军.一种双活云中心灾备方案的设计与实现[J].中国新通信,2015(23):110-111.

[8]陈瑞军,孟伟君,胡晓伟,等.城市轨道交通云平台容灾方案研究[J].城市轨道交通研究,2020,23(9):184-188.

[9]李苏雯,康进谮,李连成.城市轨道交通通信系统主备用中心切换功能分析[J].铁路计算机应用,2009,18(5):45-48.

[10]周公建,袁汪凰,李建彬.ATS系统动态时间同步方案研究[J].铁道通信信号,2021,57(10):86-91.

[11]魏喜莲.云数据中心网络安全设备部署研究[J].铁道通信信号,2021,57(4):41-47.

[12]孟娜娜,王志心,严海鑫.综合监控系统主备控制中心切换功能分析[J].江苏科技信息,2022,39(25):59-61,69.

作者:吕涛 周公建