城轨信号系统大数据平台部署方案研究

侯旭阳，田 元，陈 逸

(通号城市轨道交通技术有限公司，北京 100070)

1 大数据平台需求分析

以Hadoop 为代表的开源大数据平台目前已经在互联网相关行业得到广泛应用。在传统领域，比如交通、工业现场控制、农业等也正在得到快速的应用。传统信号系统主要依靠定制化程度较高的信号监测系统实现系统级的数据存储、统计分析功能，但是受限于平台的软硬件架构能力，无法实现大数据级的数据挖掘和统计分析功能。在信号系统范围内部署大数据平台可以较好的解决该问题。

信号系统目前针对大数据平台主要集中在以下几种应用场景。

1）用户能力评价。比如通过ATO 运行数据与司机手工驾驶数据进行对比，用以评价司机及熟练程度，或者通过分析日常维护过程的数据，分析维护人员的熟练程度，用于用户能力的精准评价。

2）备品备件库存调整。通过积累的故障历史数据（比如各设备板卡故障时间、地点、次数，设备运行时间，故障设备的电压、电流、网络设备的流量、丢包率等）和设备故障模型，预测一定时间内设备发生故障的概率，对备品备件的库存进行智能调整，用于改善现金流。

3）故障预测和故障影响评价。通过积累的历史故障数据，将故障按季节、温度等要素进行分类，分析规律性内容，用于开展针对性的故障防范措施。

上述应用场景对信号系统大数据平台提出下面技术需求。

1）平台需要存储较长时间范围内数据。原因在于信号系统的RAMS 指标比一般的非涉安系统高，故障次数相对更少，为了支撑分析历史故障数据，需要长期记录全系统的数据，这些数据在传统的维护监测系统中并不需要记录。

2）平台需要存储尽可能广泛的系统运行过程中的数据。无论是分析司机驾驶的数据还是维护人员的施工数据，都需要尽可能采集设备运行中实时产生的过程数据，而这些数据在传统的维护监测系统中也不需要记录。

3）平台的规模和造价需要控制在合理范围内。鉴于平台的最终作用在于数据挖掘和统计分析，为用户改善现金流或者节省人力资源，本身并不能直接创造利润，因此造价必须控制在合理范围内才能具备推广价值。

2 部署方案

2.1 硬件架构方案设计

服务器硬件：大数据平台的服务器硬件采用通用的、可扩展能力强和存储能力的商用服务器，最小规模条件下采用双机设计即可，同时预留后续硬件横向（增加主机数量）和纵向（增加单个主机的CPU、内存、存储）扩展能力。服务器存储空间和内存空间均需要提前估算信号系统实时数据量决定。典型的单台服务器配置包括：Linux 操作系统或者可运行Linux 虚拟机，双CPU 配置，单个CPU 至少为8 ～16 核；内存至少为64 G；硬盘至少为4块，单块在1 T 以上。

终端硬件：大数据平台的监视和维护终端对硬件要求并不高，因此既可以单独设置，也完全可以与维护网内其他用户终端合并设置（比如维护工作站）。

网络硬件：由于大数据平台所在的网络需要接入大量其他子系统的数据，为不影响信号系统传统业务功能，可采用复用维护网的方式，城轨系统中维护网可以为单网或者双网，与ATS 网或者ATC网分开设置。一方面复用维护网这样既节省了投资，又能避免过大的数据流影响。另一方面，针对既有线改造，接入维护网可以更方便的从既有信号维护监测系统（比如直连维护监测的DMS 服务器）获取数据。

与其他子系统接口：为提高网络吞吐量和系统扩展性并同时减少维护工作，与其他子系统接口均统一为以太网接口。

典型的硬件架构,如图1 所示。

图1 硬件架构图Fig.1 Hardware architecture

2.2 软件平台部署方案设计

后台：软件平台以开源软件为主，采用Apache基金会的Spark 和Hadoop 的统一部署方式。

文件系统采用Hadoop 的HDFS 分布式文件系统，该文件系统实现了高度的硬件容错性、高吞吐量的读取速度、良好的可扩展性、便捷的流式读取。

HDFS 上层部署Yarn 资源调度平台。Yarn 资源调度平台作为集群的资源管理器和运行在集群中所有节点上的节点管理器来启动和监控容器（使用一定内存、CPU 等计算资源执行特定应用程序的一系列流程的集合）。

Spark 是目前应用较为广泛的专用于大规模数据处理的通用计算引擎，由于Spark 采用内存分布数据集，因此性能相对更好。Spark 提供了大量的库，可以执行各类任务，比如SQL 数据查询引擎Spark SQL、用于实时数据处理的流计算Spark Streaming、用于机器学习的MLlib、用于图计算的GraphX。典型的Spark 和Hadoop 混合部署的方案，如图2 所示。

图2 大数据后台软件部署方案Fig.2 Big data background software deployment scheme

客户端：采用B/S 架构在客户端浏览器呈现数据统计分析、运维、开发任务的可视化界面。因此终端可以部署Windows 操作系统或者Linux 操作系统（比如维护工作站）。

根据不同岗位上用户的工作内容区分，客户端分为以下几类部署。

1) 平台维护客户端：负责监视服务器的硬件负载、计算任务执行进度、网络状态、各客户端用户状态；对各类硬件进行远程运维，比如硬件重启、更换程序、用户权限管理、计算节点管理。该终端面向运维人员。

2)任务开发客户端：负责根据其他用户需求在平台上开展计算任务程序开发、程序提交、程序调试、任务上线。该终端面向大数据开发人员。

3)统计查询客户端：发起数据查询、呈现数据统计分析结果。该终端面向使用最终计算结果信息的用户。

实时计算任务和批量计算任务的最终计算结果的呈现将通过客户端实现。从数据源到客户端的数据流如图3 所示。

从图3 中可以看出，由于采用B/S 架构，且客户端本身并不承担计算任务，因此客户端的部署位置可以比较灵活，比如车站、控制中心或者备用中心等。从而实现平台维护、结果查询、任务开发的工作岗位灵活拆分与合并。

图3 大数据平台数据流Fig.3 Data flow of big data platform

2.3 对外接口方案设计

由于信号系统的子系统较多，每个子系统的对外接口形式也都不同。比如与ATS 系统可采用以太网接口，使用非涉安的私有协议。但是CI 和ZC 均属于SIL4 的系统，针对这类安全至关重要的系统，很可能只具备采用安全协议才能进行以太网信息交互的条件。故常见有以下两种接口方案。

接口方式一：大数据平台分别跟各个子系统接口，子系统接口之间进行进程隔离或者线程隔离。这种方式适合无信号系统维护监测系统的工程。优点是可靠性较高，单个子系统接口的故障不影响其他接口信息的采集。缺点是接口开发工作量大，需要单独跟各子系统接口定制协议。

接口方式二：大数据平台只跟信号系统维护监测系统接口。由维护监测系统与各子系统接口，然后维护监测系统将其他子系统接口信息转发至大数据平台。优点是接口形式简单，开发和部署工作量小，缺点是可靠性相对较差，接口一旦故障则会丢失所有子系统的数据。

3 项目实施步骤

针对新建线路的大数据平台部署实施分为以下几步。

1)项目需求分析：明确本项目需求目标，明确需求特点，寻找需求相关性。

2)硬件和软件平台设计阶段：调研、评估本项目信号各子系统的业务数据量、实时性要求和统计分析算法复杂度，并结合本项目大数据平台部署方式进行大数据平台服务器硬件的配置选型和安装部署设计。

3)数据设计阶段：对本项目信号系统各子系统的输入的业务数据，精确到每个字段，进行存储形式的统一规范，以及人工识别设备状态与故障的相关性，人工操作效能（比如司机、调度员）与若干系统反馈指标的相关性。

4)室内大数据训练阶段：通过本项目信号系统的仿真系统生成模拟训练样本数据，并对人工识别的数据相关性在室内大数据试验平台上进行验证试验。

5)现场大数据迭代阶段：在现场部署全套大数据相关硬件、网络和软件，初期采用室内大数据训练的参数模型进行分析，在实际运营逐步产生较多数据后，结合实际的数据对模型参数进行迭代修正。

4 结语

在城轨CBTC 信号系统中，得益于车地间和地面的网络带宽大幅改善，可以获取到大量有价值的数据，从而为故障预测、用户能力评价、库存优化等任务提供有利支撑。大数据技术对海量数据的快速分析能力让这些过去低价值的数据也能随时间的逐步积累而挖掘出有效的价值，而且相对于传统信号系统的部署调试，大数据平台的部署难度反而更低，同时对既有业务系统的影响也降到较低水平。因此可以预见在未来的新建线路和既有线改造中，大数据技术将会得到更加深入和广泛的应用。