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

《列车自动监控系统主备中心设计分析.docx》由会员分享，可在线阅读，更多相关《列车自动监控系统主备中心设计分析.docx（14页珍藏版）》请在第一文库网上搜索。

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

2、BOCC)；列车自动监控系统(ATS)呼和浩特城市轨道交通工程是城轨交通云平台的试点项目，云平台作为一个集中式的硬件管理和资源动态分配平台，上面部署了列车自动监控系统(AUtomatiCTrainSUPerViSiOn,ATS)、综合监控系统(IntegratedsupervisoryControISystem,ISCS)乘客向导系统(Passenger1nformationSystemzPIS)等一系列生产业务系统，以及企业的办公管理系统(OffiCeAUtomatiOn,0A)o云平台一旦发生故障，将会对众多业务产生影响。其中ATS系统是最为关键的行车指挥系统1,一旦其出现故障，整个控制中

3、心将无法执行相应功能，因此异地设置一套独立运行的备用中心十分必要。同时，云平台依赖网络2,存在时延和网络信息安全保护不足的问题。因此传统的ATS系统设计方案不能简单地平移部署到云平台，需要结合云平台的特点，探讨相关部署要求，并对原有系统的功能进行设计调整。本文对整个系统主用中心与异地备用中心（简称“主备中心”）的功能需求、系统架构和功能实现等方面进行分析与研究。1需求分析与功能设计一般来说，主用中心是轨道交通调度员日常工作的主要场所，备用中心不会频繁使用，故备用中心的云平台资源配置可以作简化处理,基于此进行主备中心需求分析。首先考虑选址问题，主备中心的选址不仅要防范各种可能的风险、满足云平台机

4、房的建设条件，还要考虑建设成本，交通的便捷性和专业保障等多个因素，以确保主备中心的选址科学合理。其次，实际业务需求是本次研究的核心，涉及使用、维护和可靠性等多个方面，主要包括：1）灾备需求。一旦主用中心遇到地震、火灾等特殊情况，无法继续履行工作职能时，应立即启用备用中心执行监控任务，确保运营的连续性。2）运维需求。当主用中心云平台需要进行短期整体性维护时，主用中心的工作人员应借助于本地工作终端和备用中心的中央服务器，继续履行相应职责。为了保证两个中心可快速平滑切换，并具备实时监控的条件，通过对ATS系统自身功能和数据结构的梳理，细化出以下五点功能。11现场设备监控主备中心应同时具备实时监视功能

5、，不仅要对线路的列车、轨旁联锁设备、轨旁列控设备的运行状态进行监视3,也要对整个ATS系统自身设备运行状态进行监视。在控制操作上，因为指挥权的专一性要求，只有唯一的中心可以执行行车调度控制功能，所以要避免主备中心同时指挥，以确保最终责任的界定。1.2 统一设备维护主备中心异地建设，按照传统设置，需要引入两个维护团队，会带来较大的人力成本。转到云平台部署后，维护团队新增了云平台管理维护功能，相应的维护工作内容也会进一步增加。为降低维护团队的工作强度和工作压力：主备中心需要具备简洁的维护管理功能，借助于统一界面，实现对两个中心设备的远程维护；有了云平台后，对于个别设备故障，维护人员可以借助于云平台

6、技术对设备进行远程修复或者虚拟资源重新分配，大幅缩短故障修复时间。相对于传统主备中心设置，可维护性得到更好的提升。1.3 运行数据同步ATS系统包含两部分数据：一部分是现场设备状态的数据，两个中心可以实时获取，无需两个服务器之间进行同步；另一部分是主用中心才会产生的列车运行基础数据，如：用户管理、计划运行和列车出入库数据等。主用中心服务器需要在这些数据产生后，自动同步给备用中心服务器。数据同步速度必须实时，控制在秒级；数据内容也必须正确完整，在同步的过程中需要增加相关的完整性检查。两边服务器的实时正确同步才能确保两个中心业务切换的连续，对在线列车的运行不产生任何影响。1.4 主备中心切换1）单

7、一中心设备的自动切换。ATS系统是一个实时监控系统，一旦出现中央服务器的宕机，就可能导致列车无法继续运行。因此，对单一中心的中央服务器都采用了硬件独立的双机冗余部署，按照主机和备机的运行模式进行设计：备机自动监测主机的运行状态，一旦主机出现宕机或设备工作异常，备机自动升级为主机，替代主机执行监控功能。2）主备中心设备的人工切换。当主用中心发生云平台故障或者ATS系统中央服务器双机宕机故障时,控制权就需要切换到备用中心,启用备用中心的行车监控功能，切换分两种情况：一种是主用中心完全无法工作，需要备用中心的人员激活列车监控功能，在备用控制中心进行相应作业；另一种就是主用中心的工作终端和网络还是可以

8、与备用中心保持正常工作，这种场景下，主用中心的工作终端就可以切换连接到备用中心设备上，激活备用中心控制功能，进行指挥作业。这两种场景的切换任何时刻都可能发生，切换前后两个中心的状态需要保持一致，切换时间需要控制在秒级，切换操作对在线运营的列车正常运行不能产生任何影响。1.5 工作终端交互为满足主备中心的设备互为备用的需求，工作终端需要同时连接主备中心服务器：正常情况下，主用中心的工作终端用于行车调度指挥，备用中心的工作终端用于在线培训或在线维护。当主用中心发生故障情况下，主用中心的工作终端可以切换使用备用中心的中央服务器，继续进行行车调度指挥。也可以直接安排人员启用备用中心的工作终端进行行车调

9、度指挥。2选址设计呼和浩特运营控制指挥中心是集中设计的基于云平台的中心4,该中心在设计之初就预留了接入整个城市多条轨道交通线路的容量。借助于云平台强大的可扩展能力，为后续多个线路的接入提前打好基础。主用中心新建了调度指挥中心大楼，并设计了统一的机房，充分满足了主用中心云平台统一机房的建设要求。在备用中心选择方面:首先，由于备用中心属于非常用操作地点，考虑建设成本的因素下，其设备可以减配。尽管无需主用中心同样面积的机房，但也需要充分考虑GB50174.2017数据中心设计规范云平台机房建设的相关要求，能够支撑备用中心云平台的建设；其次，备用中心与主用中心在地理位置上需要相距一定距离，确保两者之间

10、满足灾备要求；最后，需考虑两个中心的专业支持保障能力，便于工作人员和技术保障人员快速到达。对既有轨道交通线路所有的场所考察后，设计了以下评估因素：建设成本尽量低、建筑空间支持云平台机房设备部署、物理地址距离主用中心10公里以上、网络建设与既有线路网络贯通便捷和工作人员出入交通方便。基于这些因素，借助层次分析法最终评价得出1号线车辆段是轨道公司既有资产，运营成本较低；有足够的建筑空间,与主用中心地址距离20公里，满足灾备需求，也可防护外部其他故障；同时该地点也与1号线和2号线相邻，便于云平台网络快速实现与2号线网络互通；车辆段具备专业的技术保障人员，紧急情况需要调配其他专业人员到备用中心工作，也

11、可统一安排通行，确保运营快速恢复6；最终确定在呼和浩特轨道交通1号线车辆段建设2号线的备用中心。3主备中心设计3.1 方案比选控制中心设备部署主要包含工作终端部署和中央服务器部署两个方面。首先，在工作人员的工作终端部署方面，尽管云平台可以完成工作终端设备的虚拟化，也可以提供一套性能简单的操作终端，简称瘦客户端，其通过云平台网络和专用远程桌面协议完成与云平台内部虚拟机交互。因为工作终端包含了安全相关的功能操作，瘦客户端的这种交互方式无法证明相关操控的安全性，故工作终端只能按照传统定制化选型硬件进行部署。其次，在中央服务器部署方面，存在以云平台技术为核心和以ATS系统技术为核心的两种方案。方案1借

12、助于云平台技术的动态分配资源和资源热迁移特性来实现主备中心功能刀。当云平台的内部网络或者计算资源发生硬件故障后，云平台管理系统实现了故障检测和资源重新调度的功能，将当前虚拟机计算需求调整到其他硬件资源进行计算，从而提高整体设备运行的可靠性。云平台支持热备份，即对在线的虚拟机相关资源进行在线备份。这些备份的虚拟机资源，在云平台主用中心发生严重故障后，借助于维护人员的操作，可以将主用中心备份的虚拟机资源迁移到备用中心云平台中（简称“热迁移”），重新启动运行，也可实现主用中心的功能。经过分析，这种方案存在以下不足：1）需要花费较长的时间才能够识别设备故障，实时性不高；2）在对虚拟机资源进行热备份时，

13、云平台无法深入到每个业务系统的内部，只能将整个虚拟机资源的数据整体复制，浪费资源的同时也需要较长的时间；3）云平台对备份的虚拟机资源热迁移后再次运行时，系统启动后会含有部分滞后的信息，可能会给现场在线运行列车发送错误的命令。需要维护人员进一步检查切换后的设备运行状态，才能投入运营。方案2：借助于业务层的主备同步方案9,配合云平台进行兼容性适配。传统的设备配置方案包括应用服务器，通信前置机和数据库服务器等独立的物理设备。转为云平台后，服务器需要运行在云平台计算单元中，见图1。主用控制中心云平台计算单元借助于云平台的硬件资源部署了冗余服务器，构建了ATS系统强大的后台计算单元，保障信号系统实时信息

14、收集、计算、分发和存档等工作。同时禁用云平台动态分配硬件资源的特性，借助于云平台资源管理系统，强制将各种服务器分别放在不同的硬件实体上，确保一旦发生单个服务器主机故障或者业务系统自身缺陷导致业务软件宕机后，业务层能快速感知10,无缝切换到物理差异的备用服务器，可解决主用中心各个服务器双机运行的可靠性问题。考虑到备用中心属于临时阶段性的使用单元，因此备用控制中心云平台计算单元采用了单机简化配置的方式,满足备用中心可临时接管整条线路行车指挥的条件。备用中心与主用中心云平台保持相互独立运行，这种方案保留了传统方案主备切换的实时性要求，同时利用了云平台设备维护的便捷性。缺点是浪费了云平台既有的资源动态

15、分配的灵活性，也增加了对云平台资源的消耗。比选上述方案，方案1节省资源，但ATS系统对实时性要求较高，无法使用。方案2虽然浪费了部分资源,但是满足ATS系统的业务需求。因此，呼和浩特轨道交通2号线的主备中心设计采用方案2设计，通过ATS系统业务自身适配云平台技术实现主备中心，确保两个中心的可用性、实时性和可维护性。3.2 切换设计主备中心设计的核心逻辑是实现两个中心之间的无扰切换，包含服务器与工作终端的切换和服务器之间的信息同步两个方面。应用服务器设计上，主用中心与备用中心需要实现同样的功能，备用中心保持与主用中心状态同步运行:主用中心各服务器双机以“主机-备机”方式运行；备用中心各服务器单机

16、以“主机”的方式运行。这种主备中心同时以主机运行的方式属于双活设计，都具备对在线列车进行监控的功能；但为了明确两个中心的指挥权：同一时刻只能有一个中心对全线设备发出控制指令。主备中心业务层面设计了“主用”状态，任何中心只有在获得“主用”状态后，相应的控制指令才可以下发给现场设备。传统ATS系统主备中心切换方案是主机和备机的切换设计:一个中心的主机故障后，自动切换到备机；一主用中心双机故障后，自动切换到备用中心服务器。这种设计经常会出现无必要的主备中心控制权自动倒切，也容易产生错误的数据同步。比如：在周期性检修时，维护人员对主用中心双机设备进行重启操作后，备用中心将会自动升级代替主用中心。检修完成后，维护人员需要操控备用中心设备,将控制权切换回主用中心。本方案中，工作人员在对主用中心设备双机重启后，在没有人工授权操作情况下，备用中心不会自动获得控制权,工作终端自动切换连接到备用中心，提供全线监视功能。等主用中心检修完毕后，工作