基于移动应用的铁道信号智能监测系统

曹 源，尤 刚，罗轶溧，李 军，周 建

（1.北京交通大学 轨道交通运行控制系统国家工程研究中心，北京 100044；2. 四川网达科技有限公司，成都 610041；3. 北京交通大学 电子信息工程学院，北京 100044；4. 中国铁路成都局集团有限公司 电务处， 成都 610041）

我国铁路信号监测系统主要由信号集中监测系统、列控监测检测子系统和GSM-R通信监测系统3部分组成。信号集中监测(CSM)系统为信号监测的主要系统，具有三级四层的体系结构，其主要功能包括监测现场设备工作状态、信息储存、报警等。系统通过CAN总线与信号机、采集转撤机、轨道电路等多个信号设备的电气参数模拟量信息、部分开关量信息进行实时联系，且为其信息获取、连接通信接口方法及维修机提供便利。虽然，我国的铁路信号系统技术装备已经达到世界先进水平，但依然存在的主要问题有以下3个方面[1]：互联性较低；数据共享不足；智能化程度较低。

随着智能手机、移动互联网的飞速发展，移动应用凭借其高互联性、数据实时共享等优点，应用范围越来越广，对于移动应用的开发与研究也取得了许多成果[2-4]。移动应用的发展，以及云数据共享技术的革新，为解决传统铁路信号监测系统存在的问题提供了可能。

建立新型铁道信号智能监测系统可以从共享数据选择、存储与共享机制、多数据库系统、数据监测规范化等关键技术入手，提高铁路信号监测检测、综合智能分析和辅助决策能力[5]。结合移动应用平台、云服务等技术而设计的铁道信号智能监测系统，能够有效地解决传统信号监测系统数据共享不足等问题，实现数据的互联互通。

1 系统设计

1.1 系统架构

基于移动的监测系统架构如图1所示，包括基础数据层，移动数据源层，云能力层和移动应用层。

图1 系统架构图

1.1.1 基础数据层

基础数据层是既有CSM系统的综合，主要包括基础报警信息、用户信息、部门信息、基础信息、工具信息、设备信息、设备模拟量、站场信息等，是系统信息的来源。

1.1.2 移动数据源层

移动数据源层与基础数据层之间通过自由协议进行数据源同步，利用包括自定义协议、标准RPC协议、HTTP1.0、HTTP2.0，Mysql协议等其他任意自由协议进行应答式、传输式等多种可扩展的方式实现双方的对接，整合基础数据层中丰富的大数据，形成数据底盘，向上对移动平台提供数据支撑。

1.1.3 云能力

云服务主要进行专业化管理，将任务和软件功能封装为通过网络可访问的服务模块，实现软件功能的柔性化管理[6]。云能力负责提供输出平台化服务能力、支撑顶层业务架构的功能。为了缩短开发周期，提升开发效率与保证质量，可以对公有云服务进行筛选评估后接入，主要包括推送云、存储云、通信云、云CDN等多种云基础设施，通盘整合其能力，结合现有平台，为移动应用层提供基础技术设施能力支撑。后续在数据能力、基础技术设施等条件成熟后，可以对相应组件进行替换，结合实际业务场景，客户需求，进行对应业务开发。

1.1.4 移动应用

移动应用本质上是基于移动的平台，具有报警管理、站场管理、人员管理、即时通信等功能。移动端的数据架构采取多种模式进行数据协同，并在此基础上与BS端共享数据源，包括用户信息、部门信息、pdf等，在此数据源中还包含了许多其他移动端专属信息，例如报警信息表、故障信息表、操作日志表、cid映射表、用户角色映射表、用户表、角色表和部门信息表。

1.2 网络架构

移动端的网络结构有两部分构成：（1）由普通的公网互联网数据中心（IDC）对外提供服务；（2）为了和C端保持通信以及维持安全性，采取被动连接的方式进行通信，C端服务主动与移动端服务建立socket连接，并采用由C端定义的协议方式进行数据交换。在移动端的视角，网络结构图如图2所示。

其中，移动检测平台运行在公网IDC机房，通过普通的web服务对移动端设备提供服务，前置部署硬件防火墙设备，以及具备安全闸功能的路由设备。对外提供服务时，通过SSL非对称加密技术对通信数据进行保护。

对C端服务器，不具备直连能力，具备动态接受能力，与C端服务设备或通过公网、联通移动专线进行交互，其中，具备防火墙以及具备安全闸功能的路由设备，其tcp通信采用对等的双向加密技术，私钥保存在双边服务器中。

图2 网络结构图

1.3 系统边界划分

系统边界划分关系如图3所示，明确各系统的运行职责。其中，C端服务提供现阶段的大部分基础业务能力支撑，包括设备模拟量收集，报警收集，报警管理，站场管理等。B端服务器与移动端服务协作开发，管理类功能在B端服务上线，移动端专属功能在移动端服务部分进行实现，包括用户登入、报警查阅、报警推送、故障智能诊断。

图3 系统边界划分关系图

其中，报警部分数据暂定由移动端接受推送，为保证C端服务正常运行。只保留最新推送数据，暂不与C段服务进行同步。

2 安全架构

目前，移动云服务的安全性需要考虑物理安全、网络安全、主机安全、数据安全、应用安全、运行安全、通信安全和终端安全等问题[7]。监测系统的安全架构主要从物理安全、网络与数据安全、运维安全和通信安全4个方面考虑。

2.1 物理安全

为了全面保障机房网络的安全可靠性，一般来说机房需要7×24 h闭路监控系统，电子巡更以及专人值守系统、IC卡与指纹门禁管理。需要按照最高标准Tier 4[8]进行实施，钢制框架结构，抗震设防烈度为8度。所有核心设施实现了2N结构，保证机房的防震、防风和防雨。防护方面，机房需要多防火、防水、防潮、防静电等基本防护功能。电压需要配置并提供稳压器和过电压防护设备，提供短期的备用电力供应（UPS设备），设置并行电力线路为计算机系统供电（2路供电），同时建立备用供电系统（发电机）。通信线路需要电源线和通信线缆隔离铺设，避免互相干扰，对数据中心的核心网络（泄露）和磁介质（损坏）实施电磁屏蔽。

2.2 网络与数据安全

加强互联网环境下云服务的安全性，主要的方法有加强对云终端的控制，加强移动网络接入和传输的安全性，加强移动云服务系统之间的访问控制等[9]。

系统硬件网络层需要通过边界控制、入侵访问等实时系统的联动，实现网络全方位安全。交换机、路由器、防火墙、服务器需要保证充分的冗余，至少保证10 M的核心带宽，100 M的动态带宽。最前置ws服务商需要做到限制网络最大流量数及网络连接数，可收集防火墙外的各类信息，用于改进阻止决策，优化阻止规则。

网络安全审计需要对网络设备运行状况、网络流量、用户行为等进行日志记录。通过互联网团队的实时入侵检测系统，能够根据记录数据进行分析，并生成审计报表。审计记录保护，避免删除、修改或覆盖等。

其他网络安全防护可以采用第三方云盾，利用DNS技术隐藏实际服务地址，通过外部流量清洗系统可以减少带宽成本付出，通过智能的请求过滤，可以有效避免公网大部分攻击方式。

为保证数据完整性，系统管理数据、鉴别信息和重要业务数据在传输和存储过程中都要进行完整性检验及必要的恢复措

施。为保证数据保密性，系统管理数据、鉴别信息和重要业务数据在传输和存储过程中都要采取加密或其他措施。备份和恢复，完全数据备份每天一次，备份介质场外存放。

2.3 运维安全

系统运维安全需要从内部人员运维安全、第三方人员运维安全、外部政策和法规要求考虑[10]。系统环境需要对机房物理访问、物品出入、机房供配电系统、空调

设备、温湿度控制的维护记录等进行管理。

系统设备需要明确设备的选型、采购、

领用、发放维护人员责任、涉外维修和服务的审批、维修过程的监控等。并对通信线路、主机、网络设备和应用软件的运行状况、网络流量、用户行为等进行监控记录。

对于系统的变更、备份与恢复、安全事件的处理和应急预案管理，都需要遵循相关制度，并做好相应事件的记录和报告。

2.4 通信安全

针对公网服务，无论如何均有链路出口，为避免移动端安全服务架构破解导致C端服务暴露的根本问题，移动端服务必须永不主动向C端服务（内网）发起请求，C端服务所在的IDC防火墙无需敞开公网入口，移动端服务在安全加密的保证下，仅接受C端白名单出口IP的tcp链接请求，并在链路上采用对称加密与数字签名技术，保证数据在链路传输的安全性。

3 系统核心模块

系统平台的核心模块主要有网络处理、报警同步、智能故障诊断、系统记录和登录管理5个模块，如图4所示。

图4 平台核心模块图

3.1 网络处理

网络处理层采用apache mina网络框架。mina底层基于Java NIO, 它基于TCP/IP和UDP/IP协议提供了抽象的、事件驱动的、异步的API。

网络处理模块包含两部分：二进制解码模块和消息实体处理模块。消息实体是二进制消息对应的可读形式内容对象。

二进制解码模块的核心包括消息分辨器和对应消息的解码器。分辨器用来识别消息类型，然后交给具体的解码器来解析二进制内容。二进制解码模块的输出结果是消息实体，即可读的消息对象。

消息实体处理模块接受二进制模块的输出结果。根据消息对象类型从服务注册中心选取处理该消息的处理服务，目前基本所有的实体消息处理服务主要用来持久化消息内容以及将相应的报警消息推送给目标客户端。

3.2 报警同步

报警同步的方式采用被动接收模式。报警接收系统在启动时会开启TCP连接监听，等待报警推送服务器连接。其连接模式采用长连接模式，通过心跳保持连接有效性。当收到连接请求时，报警同步模块的工作就是建立连接，在检测到某台设备发生报警的时候将报警消息推送给接收服务器。另外，如果因为某些原因连接断开，报警同步模块需提供重连功能。

3.3 智能故障诊断

建立设备的故障数据库，当系统出现故障时，通过神经网络、隐马尔可夫模型（HMM，Hidden Markov Model）等智能故障诊断方法实现故障的智能分析与实时追踪。此外，系统也能通过故障预测方法对设备进行故障的预测与预警，实现对轨道电路、道岔转辙机等设备的故障趋势预警与故障诊断。

3.4 系统记录

系统操作记录完成了用户在移动端所有相关操作的记录工作。记录动作穿插在几乎所有的可操作动作中。并实时持久化到数据库。用户在查看操作日志时，系统会根据当前用户的角色来筛选出当前用户可查看的用户范围。根据业务规定，用户只能查看自己下属或者跟自己平级的操作日志。

3.5 登录管理

移动端的用户信息共享了C端的用户信息。所以一份用户信息可以在C端和移动端同样生效。登录管理包含移动端的登录登出功能，更换密码功能，以及忘记密码重置功能。在用户登录成功后需要完成cid跟用户的绑定，以实现消息推送。

4 移动客户端

4.1 系统流程

系统的移动客户端用WEEX-EROS进行开发，其运行流程图如图5所示。

图5 运行流程图

在local eros-cli下通过eros init生成客户端的开发模板，并通过eros dev启动服务进行实时开发效果查看和debug调试，通过eros install更新开发平台所需的eros依赖，通过eros pack对相应平台内置信息打包，通过eros build生成全量包、增量包，并内置与更新服务器交互逻辑，形成对应ios和Android的平台。

4.2 移动端通信流程

当业务需要获取数据时，整个通信流程是业务发起请求调用，使用this.$fetch接口，此接口会调用框架底层widget/axios基本封装，对发送数据进行简单的封装，通过bmAxios接口调用客户端底层方法BMAxiosNetworkModule发出HTTP请求。后端返回数据之后，客户端接收到数据，将数据返回到框架底层，框架底层会将返回数据进行统一数据处理，最终返回到业务方。

4.3 通信安全保障

业务方发起请求之后，框架底层会对发送数据进行统一包装，包装内容将所有数据进行JSON.stringify 转成字符串，将字符串通过加密生成密钥，并将密钥带给客户端，客户端使用同样的方式进行解密，对完整性进行校验。

发起请求时，业务还会携带用户信息，客户端会对用户信息进行校验，客户端会对用户真实性进行校验。

4.4 实例应用

在使用移动客户端时，需要进行用户的账号登录。输入已授权的账号才可登入移动客户端系统的主界面。

在移动端的系统主界面下可以进行报警查看、预警信息查看、人员追踪、图纸查看、站场查看、历史曲线查看、通信状态查询以及系统状态查询。

智能监测系统会实时记录各项数据，对不同站场的数据进行区别并统计，对一级报警、二级报警、三级报警等信息分别进行记录，并将相应的数据绘制成对应的图表。系统自动将各项数据上传，将数据保存在云服务器中。通过移动客户端就可对各项信息进行查询。

该系统已在成都铁路局投入使用。图6为基于移动的监测系统移动客户端的主界面。图7为2017年11月7日—11月14日站场区间一级报警的统计列表。图8、图9为各级报警的统计次数，以及报警级别占比的比例图。

图6 移动客户端主界面

图7 站场报警次数统计

图8 各级报警统计次数

图9 报警级别占比图

5 结束语

基于移动应用的铁道信号智能监测系统结合了云存储、大数据、4G无线通信等技术，具备实时报警、监测数据查看等功能，通过无线通信将报警记录与监测数据实时保存到云端，并且生成图表信息，各级报警记录、预警记录和历史数据。各项信息可通过客户端与移动端随时查看，实现了对历史数据的充分挖掘。此外，系统能够结合具体的业务场景，对各设备进行智能故障预测与诊断。该系统已在成都铁路局实际应用，显著提升了各个监测系统之间的数据互联互通性，信号数据得到有效利用，实现了对信号系统各类设备的运行方案优化功能。