一种基于云边协同的高速铁路智能行车调度安全卡控系统

摘要

本发明公开了一种基于云边协同的高速铁路智能行车调度安全卡控系统，通过将计算和智能推向更接近实际的前端，改进传统系统在多源异构数据处理方面的问题，减少车站的行车控制单元数据处理压力，使其更集中精力于行车安全卡控业务处理；与此同时，缩减中心化和集中式处理规模，弱化中心云服务器耦合焦点程度，减轻数据集中处理压力，使其专注统筹调度和流程掌控。

说明书

技术领域

本发明涉及轨道交通技术领域，尤其涉及一种基于云边协同的高速铁路智能行车调度 安全卡控系统。

背景技术

高速铁路行车调度指挥系统集中控制区段内信号设备，指挥管理运行列车，实现行 车调度和安全卡控功能，是高铁日常运营管理的中枢。高速铁路智能行车调度系统在现有调度指挥系统基础上，结合“智能铁路”发展需求，基于列车运行状态信息的全面感 知、传输、处理和共享集成，协调优化铁路各业务流程和各类资源，在进路和命令安全 卡控、行车信息数据平台以及列车运行自动调整等方面进一步优化完善，以较低成本达 到保障安全、改善运营管理以及提高运输效率和系统智能化水平的目的，是提升高铁调 度指挥系统的优化决策和协同处置能力，尤其是突发事件决策处置能力的关键核心内 容。作为对现有系统的补充和完善，高速铁路智能行车调度系统在拓展既有自律卡控条 件和自律检查范围基础上，通过加强与运输信息集成平台、电力供应监测平台、大风监 测报警平台、地震预警监测平台等系统的结合，重点研究和完善了突发事件下进路和命 令安全卡控功能，形成了基本适应我国高铁运输需求的智能行车调度子系统——高速铁路 智能行车调度安全卡控系统。

随着互联网信息技术、大数据、云平台等现代技术日渐成熟和普及，中国高铁步入“智慧铁路”和“大数据铁路”时代：高铁数据资源总量呈指数级趋势暴增，新增数据 类型涌现且繁杂。在大数据技术发展初期，云计算和大数据自然而然形成互相促进、互 相依赖的相辅相成关系。但伴随着智能CTC前端检测节点和检测设备的广泛铺设，传统 大数据中心化处理方式暴露的资源集中和故障集中等问题，以及由此带来的计算压力、 网络压力和处理延迟等难题，部分方面已不适应高铁智能行车调度安全需求。与此同 时，我国疆域辽阔，自然环境多样，列车运营组织模式复杂，风雨雪震和设备故障等人 为因素和自然灾害导致的具有严重不确定性的突发事件在飞速发展且已成网的高铁路网 规划背景下，给行车调度和列车运行带来巨大安全隐患。围绕“智慧铁路”，科学利用 大数据和应对大数据，全力打造高可靠性、高可用性、高安全性和高智能化水平的高铁 智能行车调度安全卡控系统，对风雨雪震和设备故障等突发事件所造成影响智能分析和 全面预测，在突发事件下列车运行进路和命令安全卡控等方面寻求突破和全面优化完 善，对进一步提升列车运行控制的可用性、安全性和自动化水平有极大促进作用和重要 现实意义。

边缘计算是指靠近物或数据源头的一侧，融合网络、计算、存储、应用核心能力为一体的开放计算平台，通过多维感知数据采集和前端智能处理技术将融合计算能力和智能能力的服务环境推向前端。作为云计算向边缘侧分布式拓展的新触角，边缘计算可为 高铁智能行车调度提供实时、动态和智慧化的数据服务和计算服务，改进云端计算在多 源异构数据处理、带宽负载和资源浪费、安全和隐私保护等方面问题，有效弥补现有大 数据云中心集中处理方式的不足。因此，为降低高铁突发事件对行车安全的影响，合理 协调和调度大数据下的数据和资源，融合云计算和边缘计算，设计一种基于云边协同架 构的高铁智能行车调度安全卡控系统，是当前高铁智能行车调度的现实需求和发展方 向。

目前高速铁路智能行车调度安全卡控系统主要有如下几种方案：

方案一、大数据环境下，基于云中心和数据单一汇集的高速铁路智能行车调度安全 卡控系统。

该方案在铁路局中心架设单一高可用中心云服务器。处于监测网络边缘的各类突发 事件前端节点以及调度系统内部各车站行车控制单元通过一级或多级接口服务器连接至 中心云服务器。系统结构示意图如图1所示。网络边缘监测节点采集数据后，将未经处理的原始数据通过接口服务器直接上传至中心云服务器。中心云接收前端数据并对其进行基础预处理后，一方面执行数据持久化操作；另一方面执行数据再加工操作，并按照过 滤规则和映射规则，将加工数据转发至实际行车控制单元，并由行车控制单元按照采集 事件数据类型、即时运营状态和安全卡控规则，进行突发事件下最终行车安全处置操 作。

然而，方案一的缺陷在于：实现简单、直接、粗犷，所有基础数据和服务调用都通过统一的中心云服务器进行中转和处理。在数据量增加、业务变得复杂趋势下，中心云 服务器成为耦合焦点。前端监测节点将大量未经处理的原始数据直接上传中心云服务 器，极大增加网络带宽压力，并由此带来数据的传输延迟和处理延迟；自动化水平不断 提高的前端节点的计算资源和存储资源未被利用，相关压力被直接转移至中心云和各行 车控制单元；中心云和行车控制单元需要应对多源异构数据，不利于系统扩展；同时， 中心云作为资源集中和数据集中的单一节点，承担了过多的数据处理和转发功能，单点 故障对系统可靠性影响严重。

方案二、大数据环境下，基于云中心和数据分散汇集的高速铁路智能行车调度安全 卡控系统。

相较于方案一，未经处理的原始数据仍然直接上传至中心云服务器，由其执行数据 持久化操作。但车站行车控制单元的数据来源由中心云变为了源头节点，并且数据类型由预处理后的加工数据变为了原始数据。方案二对应系统结构示意图如图2所示。相较于方案一，方案二中行车控制单元直接接收关联节点的原始监测数据，在紧急突发事件下 通过缩减中转环节，降低数据网络延迟。中心云服务器内部的数据转发业务予以精简， 各车站终端降低了对中心云的单一依赖，系统可靠性有所提升。

然而，方案二的缺陷在于：同方案一，方案二同样存在网络带宽压力、数据传输和处理延迟、前端节点资源浪费等问题。此外，中心云的多源异构数据处理功能转移至各 行车控制单元，在增加行车控制单元实现难度的同时，降低了系统整体扩展性；监测节 点与行车控制单元的映射关系需要在边缘监测节点加入网络时予以确认，并由人工静态 配置于节点内部或节点归属的接口服务器，降低了数据转发灵活性和动态性。

方案三、实现方式单一的、持久保持的长连接通信方式。

无论是方案一还是方案二，既有调度系统各模块间建立网络连接后，均持续保持和 维护该连接。当连续一段时间无有效监测数据发送时，两端连接模块通过心跳消息维持此连接。相比于“即用即连，不用即退”的短连接方式，长连接可以省去较多底层网络 建立和关闭操作，减少网络资源申请/释放频率，节约网络建立和数据传输时间，适用于 频繁请求资源和持续数据发送的应用场景。

然而，方案三的缺陷在于：未考虑实际场景中的数据传输量级和传输持续时长的长 连接方式，在偶发数据传输和夜间持续无数据传输等场景下，浪费网络资源。不同于短连接的“存在即有效”特征，长连接方式下，服务端需要独自维护和管理网路连接；周 期性的心跳信息也加重网络传输数据量；此外，有限的网络资源在持续保持的网路连接 下，限制了服务端的进一步扩展，不适用于海量前端节点和接口服务器的应用环境。

发明内容

本发明的目的是提供一种基于云边协同的高速铁路智能行车调度安全卡控系统，充分 挖掘和利用大量智能化前端边缘监测节点的计算资源、存储资源和网络资源，减少节点 资源浪费，提升高速铁路大数据环境下智能行车调度数据的计算效能、传输效能、网络效能和应用效能。

本发明的目的是通过以下技术方案实现的：

一种基于云边协同的高速铁路智能行车调度安全卡控系统，包括：部署在中心区域 的中心公有云、部署在车站区域的车站子云及行车控制单元、以及部署在网络侧的边缘子云及边缘监测节点；其中：

所述中心公有云，负责边缘监测节点和行车控制单元的动态调度和维护功能，以及 存储来自边缘子云的原始数据；

所述边缘监测节点，用于实时采集并监测指定类型突发事件状态，形成原始数据；以及正常状态下按照突发事件处置规则将原始数据处理为加工数据；还负责将原始数据及加工数据传输至边缘子云；

所述边缘子云，用于将加工数据传输至相应的车站子云，以及将原始数据传输至中 心公有云；

所述车站子云，用于将加工数据传输至相应的行车控制单元；

所述行车控制单元，接收加工数据，并用于内部业务逻辑和安全卡控操作。

由上述本发明提供的技术方案可以看出，通过将计算和智能推向更接近生产实际的 前端，改进传统系统在多源异构数据处理方面的问题，减少车站行车控制单元数据处理压力，使其更集中精力于行车安全卡控业务处理；与此同时，缩减中心化和集中式处理 规模，弱化中心云服务器耦合焦点程度，减轻数据集中处理压力，使其专注统筹调度和 流程掌控。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的 附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得 其他附图。

图1为本发明背景提供的方案一的系统结构示意图；

图2为本发明背景提供的方案二的系统结构示意图；

图3为本发明实施例提供的一种基于云边协同的高速铁路智能行车调度安全卡控系统 结构示意图；

图4为本发明实施例提供的边缘监测节点的工作流程及其加入系统网络的流程图；

图5为本发明实施例提供的行车控制单元的工作流程及其加入系统网络的流程图；

图6为本发明实施例提供的网络边缘侧的数据流向示意图；

图7为本发明实施例提供的系统各部分的通信连接示意图；

图8为本发明实施例提供的消息窗口示例；

图9为本发明实施例提供的消息窗口机制下的发送流程。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地 描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。

高速铁路行车调度指挥系统采集监测数据具备多源、异构和海量等特点。为将多来 源、多类别、多形式的数据及时、准确、有效且安全地整合和应用到列车运营管理和突发事件处置流程中，本发明实施例提供一种基于云边协同的高速铁路智能行车调度安全卡控系统，图3展示了系统的整体结构，及结构内各部分数据传输路径与数据类型。

从结构方面来说，系统主要包括：部署在中心区域的中心公有云、部署在车站区域的车站子云及行车控制单元、以及部署在网络侧的边缘子云及边缘监测节点。

从各部分的功能及数据传输路径与数据类型方面来说：

1)所述中心公有云，负责边缘监测节点和行车控制单元的动态调度和维护功能，以 及存储来自边缘子云的原始数据。

2)所述边缘监测节点，用于实时采集并监测指定类型突发事件状态，形成原始数据；以及正常状态下按照突发事件处置规则将原始数据处理为加工数据；还负责将原始 数据及加工数据传输至边缘子云；

3)所述边缘子云，用于将加工数据传输至相应的车站子云，以及将原始数据传输至 中心公有云；

4)所述车站子云，负责行车控制单元功能替补和数据中转功能，用于将加工数据传 输至相应的行车控制单元；

5)所述行车控制单元，接收加工数据，并用于内部业务逻辑和安全卡控操作。

通常情况下，精简的加工数据立即发送至车站，用于行车控制；详尽的原始数据延迟发送至中心公有云，用于错时存储和处理。但实际应用中，原始数据和加工数据，都 是可以传送至中心公有云。

针对智能行车调度系统突发事件采集监控应用场景特点，系统设计和实现了多协议 解析引擎、数据(预)处理引擎、数据存储引擎和对解析、处理和存储进行配置管理的 规则管理引擎，各引擎单独或组合构建于系统各个部分中。

本发明实施例提供的系统主要考虑如下问题：

1)在设备资源利用、多源异构数据处理、带宽负载和安全隐私保护等方面寻求突破，解决传统大数据环境下智能行车调度安全卡控系统诸多弊端，研究基于云边协同的 智能行车调度安全卡控系统架构：分布式的边缘计算系统充分发挥各个边缘平台的协作 效率和边缘设备资源利用率，融合大数据的中心化理念和边缘计算的前端化理念，设计 基于“云边协同”的混合云和边缘的协同计算框架，将既有智能行车调度中中心化和后 端化的行车安全卡控业务分散和前移至突发事件前端采集设备。

2)架构设计及系统实现中的数据研究。通过数据格式、通信协议和数据流向定位，以海量节点应对海量数据，研究建立高速铁路智能行车调度数据的信息分类和交互模 型；利用单节点体、节点子云及中心调度云集从海量异构且实时的数据中挖掘出能有效 支持突发事件下智能行车调度安全卡控的价值信息；借助云边协同、以边为主模式，有 效前移数据处理和安全卡控业务。

3)基于云边协同的高速铁路智能行车调度安全卡控系统实现细节研究。以数据为中 心，建立边缘监测节点、边缘子云、车站子云、车站行车控制单元以及中心公有云的多层级间不同模块的底层连接关系和上层逻辑关系；研究系统中各模块的动态加入/退出流程；研究建立基于事件、数据及应用场景的模块间高效连接方式。

4)系统的数据安全和服务安全研究。针对突发事件下的智能行车调度需求特征，以 用户体验质量为导向，通过前期边缘监测节点能力认证、中期数据传输安全加密和后期消息有效性和可靠性验证技术，统筹协调保证云边协同模式下的数据安全和服务安全。

下面从三个方面来对本发明做详细的介绍，分别为：系统中各部分原理介绍、系统总体工作原理、以及通信机制。

一、系统中各部分原理介绍。

1、边缘监测节点。

边缘监测节点，负责单一突发事件监测和事件数据处理功能，主要包括：

数据采集层：通过广泛部署于现场的各类探针和传感器，实时采集并监测指定类型 突发事件状态。

数据描述层：通过数据描述引擎将数据采集层上传数据以格式化数据形式记录事件 状态及其变化过程；通过数据预处理引擎进行数据加工处理形成突发事件监测的原始数 据，使其符合系统后续处理的规范化要求。

数据处理层：依据边缘监测节点在加入网络时从中心公有云获取的突发事件处置规 则，通过数据处理引擎实现突发事件状态变化到行车卡控处置结果的映射，形成突发事件处置的加工数据。相比原始数据，加工数据数据量少，信息集中度高，结果指向性明 显。

数据传输层：按指定协议(具体协议内容在后文进行介绍)分别对原始数据和加工数据进行打包操作；与边缘子云建立基于数据和场景的网络连接，将打包好的原始数据 和加工数据放入消息传输队列，发送数据至边缘子云。

2、边缘子云。

边缘子云由设定的管辖范围内、且具有相同事件监测类别的边缘监测节点组合而成。

边缘子云负责管辖范围内边缘监测节点的功能替补、数据缓存和中转，主要包括：

1)当边缘监测节点由于资源缺陷或设备故障时，边缘监测节点的数据处理层业务无 法开展，则原始数据直接由数据传输层上传至边缘子云，边缘子云通过集成数据处理引擎，将原始数据处理为加工数据，实现部分边缘监测节点缺失功能。

2)在行车控制单元获取处理完毕的加工数据并将其应用于实际行车业务后，车站或 中心对获取海量原始数据的紧迫性大为降低。边缘子云依托较为丰富的存储资源，通过数据存储引擎实现延迟数据(即原始数据)的缓存功能，降低网络带宽争抢，提高网络 故障时的数据安全。

3)边缘子云作为网络侧与中心区域和车站区域的接口，还负责边缘监测节点数据的 上传和中心公有云数据的下达等数据中转功能，例如，在边缘监测节点加入系统网络时，将来自中心公有云的边缘监测节点所关联车站的行车控制单元的信息及突发事件处置规则、以及来自车站子云的相关行车控制单元的专用数据转发至边缘监测节点。

3、中心公有云。

既有方案中的中心云退化为本发明实施例中的中心公有云。相较于传统中心云，中 心公有云减少了数据加工和拓转任务，降低了数据时延敏感度，增加了整体调度和协调功能。通过多协议栈的解析、处理、存储等设计，中心公有云解决了数据多源杂乱和数 据架构不统一、存储入库困难等问题。中心公有云主要功能包括：

1)负责网络边缘监测节点和行车控制单元的动态调度和维护功能。在模块加入/退出 网络时，中心公有云负责节点能力认证、基础数据分发、资源协调调度以及节点最后遗 嘱登记和触发通知等。

2)离线数据持久化操作中，多协议解析引擎根据已部署协议栈配置，启动协议相关 监听功能或数据拉取功能，负责海量边缘监测节点采集监测数据的拆包和解析任务，并将输出交由存储引擎按照存储规则一体化配置实现数据的按类别、时间和场景等分类持久化存储。

3)依托智能行车调度突发事件大数据，挖掘和应用大数据中高速铁路行车安全有效 信息，评估和制定突发事件在智能行车安全卡控中的影响和应对策略；将更新后的突发事件处置规则主动推发至关联节点，实现基于大数据的安全卡控规则自主学习。

4、车站子云。

铁路局内单一线路、具有较大关联度的车站行车控制单元组合为车站子云。车站子 云负责数据转换、数据缓存和数据中转功能，主要包括：

1)对车站子云所属车站所关联的边缘监测节点上传数据进行拆包和解析，是边缘监 测节点数据传输的逆向过程。

2)实现较短时间窗口下的突发事件实时数据的缓存功能。不同于边缘子云的长时间 缓存，车站子云处理的突发事件实时数据具备时间敏感性。在车站行车控制单元或网络故障时，车站子云的数据缓存功能提高了数据可靠性和稳定性，缓存队列的数据削峰功 能提升了车站单原始数据处理能力。

3)负责车站行车控制单元与外部的数据中转功能。

5、行车控制单元。

行车控制单元可以是现有行车调度指挥系统中车站操作设备，主要包括车务终端、 值班员终端和自律机等。行车控制单元接收处理完毕的规整数据，直接用于单元内部业 务逻辑和安全卡控操作，进一步保障列车行驶平稳和高铁行车安全。

二、系统总体工作原理。

本发明实施例中，系统实行服务注册和消息订阅机制；边缘监测节点通过突发事件 状态监测、数据采集和处理行为，对外提供数据服务和计算服务，是事件消息的发布者，以及数据和服务的提供者；边缘子云执行数据中转业务，是消息的二级发布者；车 站子云或车站行车控制单元通过兴趣数据订阅，接收边缘监测节点服务，是事件消息的 消费者，以及数据和服务的接收者；中心公有云保存所有边缘监测节点、边缘子云、车 站子云和行车控制单元信息及状态，并且维护一个服务名到服务实例的映射关系，即服 务注册表；中心公有云通过服务注册表和预置规则，实现系统内部管理、服务调度和数 据分发工作，是服务中介员和消息代理者。

本发明实施例中，服务名是具体服务的文字标识，比如某一个边缘监测节点提供突 发风事件的计算服务，用户可以设定相应的服务名。服务实例是提供这个服务的物理设备信息+逻辑服务信息，包括提供服务的节点IP、节点服务名、提供服务的类别等。服务 名和服务实例，在文字上，可相同，可不同。接收服务的设备首先根据兴趣数据获取服 务名，再通过映射关系，获取提供该服务的基本信息，通过这些基本信息，连接前端边 缘监测节点，接收该服务名对应服务实例的服务。

边缘子云、车站子云以及中心公有云一般在系统架设初期，通过工程部署，以极简功能运行。在系统完整周期内，三者不做基础功能调整，仅随终端(包括边缘监测节点 和行车控制单元)的动态加入，边缘子云和车站子云规模不断扩大，中心公有云数据不 断完善。三者业务展现于终端业务之中。

下面着重介绍边缘监测节点、行车控制单元的工作流程及其加入系统网络的流程、 以及系统中各部分所涉及的数据处理方式。

1、边缘监测节点的工作流程及其加入系统网络的流程。

如图4所示，主要包括：

步骤S1、边缘监测节点启动，读取预先输入的静态配置，包括监测突发事件类型、边缘子云地址以及系统相关参数和业务参数，完成初始的初始化操作。

步骤S2、边缘监测节点根据预置地址，连接边缘子云，向边缘子云发起注册，并申请中心公有云信息。

步骤S3、边缘子云根据安全规则，检查边缘监测节点连接有效性，包括连接信息有效性与登录认证信息有效性；当检查通过后，边缘子云记录边缘监测节点信息，在边缘 子云内部完成节点注册登记业务，并向节点返回中心公有云信息。

步骤S4、边缘监测节点收集本地能力认证信息，以加密连接方式向中心公有云发送 注册申请、能力认证申请和最后遗嘱信息；如果边缘监测节点通过中心公有云的能力认证，则能够对外提供数据服务和计算服务；否则，只能对外提供数据采集和传输服务。

步骤S5、中心公有云根据边缘监测节点的能力认证信息，结合边缘监测节点监测突 发事件类型及关联的行车控制单元数量，综合判定边缘监测节点是否具备对外提供边缘 计算的能力；同时，中心公有云登记新加入的边缘监测节点信息，更新边缘子云管辖列表、以及行车控制单元关联边缘监测节点列表；中心公有云同步更新服务注册表；中心 公有云记录边缘监测节点最后遗嘱信息。

步骤S6、边缘监测节点的综合能力满足指定事件下的边缘计算条件，中心公有云通 过节点能力认证；中心公有云检索根据边缘监测节点、边缘监测节点监测事件以及事件数据类型建立的调度规则，向边缘监测节点下发其关联的行车控制单元的信息；同时下 发目前最新的通用突发事件处置规则；其中，边缘监测节点通过边缘子云实现与中心公 有云的信息交互。

行车控制单元的信息通常包含所属车站的IP地址、车站站名、车站的典型业务场景、 车站关注突发事件类型等。通过这些信息，边缘监测节点可以确定是否需要向该车站提 供服务，以及如何(通过网络)连接车站。

示例性的，突发事件可以包括风雨雪震、设备故障等事件。

单一边缘监测节点只监测单一突发事件，位于一个具体的确定的位置，服务于附近 关联车站。

车站由于所处位置及行车业务侧重点的不同，关注的突发事件类别也可能不同。例 如，对于风口区域的车站，行车业务对风事件敏感，在大风天气下，多点多级别连续报警、限速区段重合等复杂报警处置情况频繁发生，调度员需频繁对多列车或同列车多次 传送不同限速命令，大风报警处置工作量大导致调度员无法及时处置所有报警信息，造 成大风报警处置滞后，同时可能存在来不及处置及漏处置的风险。对于山体区域的车 站，对雨、山体滑坡等事件比较关注。例如，不同车站可以侧重于货运业务、普速线路 客运业务、高铁线路客运业务等。因此，中心公有云基于边缘监测节点(包括节点所处 位置、监测事件)、车站单元(业务运营、所处位置、关注的突发事件)，以及边缘监 测节点与车站单元的关联关系(包括位置相关性、服务相关性等)，综合建立调度规 则。

步骤S7、边缘监测节点根据中心公有云返回的关联车站的行车控制单元信息，主动 连接相关的车站子云或车站行车控制单元，申请行车控制单元的专有数据。

本发明实施例中，边缘监测节点可以连接车站子云，也可以连接行车控制单元。

整体设计思路为车站子云有两部分功能：1)车站行车控制单元的替补：当行车控制 单元有暂时性网络故障或其他异常时，车站子云可以临时替代行车控制单元的功能；2)车站子云内部所有行车控制单元的公共功能：当本线路内所有车站行车控制单元有一些公共要求(本线路内的功能特性)时，由车站子云统一对外提供相关信息，一方面可以 减轻车站行车控制单元的负担，另一方面车站子云的网络连接效率和质量也更高。

因此，边缘子云请求车站行车控制单元的独有安全卡控策略(规则)时，相关的信息可以来自于行车控制单元，也可以来自于相应的车站子云。

行车控制单元的专有数据包括：车站的网络连接信息，如IP地址、车站域名、车站连 接方式等；车站站场信息，如车站站名、车站站码、车站股道信息、车站进路信息等。

步骤S8、边缘监测节点接收相关车站子云或者行车控制单元返回的专有数据；所述 专有数据包括车站特殊需求、事件监测特殊需求以及车站特有的突发事件处置规则等。

本发明实施例中，上述“特殊需求”、“特有”等要求都是基于车站行车需求来设 定的。可以从车站所处位置以及车站行车场景两个方面来考虑：

1、从车站所处位置(即所处自然环境)考虑。

1)山区行车，对雨事件以及关联的山体滑坡事件等自然灾害比较敏感，或者遇到这 类突发事件的概率较高。因此，相关区域车站会对监测雨、山体滑坡等突发事件的边缘监测节点的服务的需求度较高。2)风口区域，如大西北、内蒙、张家口等区域，风事件 对行车安全影响较多，相关区域车站对这类事件的边缘监测节点的依赖度更大。

2、从车站行车场景来考虑。

对于高铁线路，列车均为电力机车，行车速度快，对电力监测事件较为关注，相关提供停供电监测的边缘监测节点的服务，对行车安全有较大影响。部分既有货运线路， 内燃机车较多，行车速度慢，对电力供应监测的服务的依赖度稍低。另外，车站行车可 为高速客运专线、普速客运专线、客货共线、货运专线等。线路等级越高、运行速度越 快，一般来说，对安全事件监测需求越高。

步骤S9、边缘监测节点根据中心公有云以及行车控制单元返回的信息，完成最终初 始化操作；之后边缘监测节点开始监测指定类型突发事件状态。

到此阶段，边缘监测节点已收集到启动完整服务的所有动静态数据和规则，从而完 成最终初始化操作。具体来说：边缘监测节点启动的数据，包括本地静态数据，以及外部交互的动态数据。动态数据是中心公有云、行车控制单元等返回的数据。静态数据， 是存储于边缘监测节点本地的数据，比如，基本的监测参数(启动服务等级、监测间 隔、数据存储时长等，也包括边缘子云的连接信息等)。边缘监测节点就是通过这些连 接信息，动态连接边缘子云、车站子云、中心公有云以及行车控制单元等，获取动态数 据。

步骤S10、边缘监测节点的数据采集层、数据描述层和数据处理层持续不断地提供数 据采集服务和计算服务；输出的原始数据和加工数据上传至边缘监测节点的数据传输层。

步骤S11、边缘监测节点数据传输层将数据传输至边缘子云；对原始数据，采用延迟 传输或实时传输的方式，对加工数据，采用实时传输的方式。

步骤S12、边缘子云将加工数据实时持续传输至车站子云，并由车站子云拓转至关联 行车控制单元。

步骤S13、边缘子云延迟将原始数据和加工数据传输至中心公有云，并交由其持久化 存储和数据挖掘。

在上述步骤S4中边缘监测节点搜集自身能力信息，以便中心公有云对边缘监测节点 进行能力认证。相关的原理如下：边缘监测节点程序初始化启动后，读取本机软硬件信息，包括可用于提供计算服务的计算资源信息(CPU等)、可用于提供数据存储服务的 存储资源信息(硬盘、内存等)、可用于提供数据传输服务的网络资源信息(网络带 宽、通道质量等)以及操作系统等基本信息。边缘监测节点将上述能力认证信息以通用 数据格式(如XML数据格式)，连同注册申请一并发送至中心公有云。中心公有云维护 常用服务能力认证评分表。当中心公有云接收到节点能力认证申请信息时，依据评分 表，获取节点各项子能力独立初始评分。中心公有云再结合节点区域位置和区域特征， 以及待监测事件类型等，生成基于事件类型和应用场景的节点综合能力认证评分。当该 评分高于阈值，满足事件监测要求时，认定该节点具备对外提供服务的能力。否则，该 节点只对外提供事件监测和数据传输功能，相关逻辑计算和业务卡控由子云完成。举例 说明：气压变化较大区域的边缘监测节点，当其监测大风事件时，节点的运算能力相应 要求较高；反之，较低性能的节点也可对外提供正常服务。

在上述步骤S4中边缘监测节点还将最后遗嘱信息传输给中心公有云。最后遗嘱信息 用于应对网络不稳定环境下，边缘监测节点无故与区域中心的边缘子云中断连接，导致部分突发事件监测功能失效问题。相关原理如下：在订阅边缘监测节点发布消息的终端 范围发生变化时，包括边缘监测节点动态加入网络、车站行车控制单元动态加入/退出网 络，边缘监测节点向中心公有云制定最后遗嘱规则，以保证突发事件下的人工介入功 能。具体来说，最后遗嘱信息主要包括：包括边缘监测节点信息、监测事件信息和关联 的行车控制单元；边缘子云定期监测边缘监测节点的状态，当边缘监测节点发生异常 时，边缘子云通知中心公有云，触发相应边缘监测节点的最后遗嘱机制；中心公有云依 据相应边缘监测节点的最后遗嘱信息，向相关联的行车控制单元发送报警提示。相关联 的行车控制单元可以直接剔除该异常节点监测规则，可以直接提升受影响范围行车安全 等级，也可以报警提示引入人工介入。相关业务逻辑处理方式由现场动态自适应配置和 调整。

当边缘监测节点发生故障后，触发遗嘱事件；中心公有云需要确定发生故障所涉及 的边缘监测节点。边缘监测节点信息通常包括：IP地址、节点名称、节点监测事件类别、可作为参考的节点提供服务的一些历史状态信息等；此外，还需要确定发生故障的边缘 监测节点所关联的行车控制单元的相关信息(例如，车站单元的IP地址、车站站名、车站 归属调度台、车站已订阅的边缘节点服务等)。

2、行车控制单元的工作流程及其加入系统网络的流程。

本发明实施例中，车站子云或行车控制单元通过消息主题与网络侧建立关联；消息 主题为<边缘监测节点ID、事件类型>的二元组；线路内部的消息订阅、数据解析以及专有行车卡控策略分发等操作和业务，可统一部署于车站子云，也可分散至各车站前端， 具体情况要结合现场需求和设备状况。消息主题是从车站子云以及行车控制单元的角度 提出来的，车站子云或行车控制单元通过订阅的主题或者说订阅的服务，接收边缘节点 服务。

如图5所示，行车控制单元的工作流程及其加入系统网络的流程包括：

步骤S1、行车控制单元启动，读取预先输入的静态配置，包括站场信息、进路信息和业务参数、以及车站子云信息，完成初始的初始化操作。

步骤S2、行车控制单元搜集本地信息，包括线路信息、车站信息以及硬件信息和网络连接信息；行车控制单元打包本地信息，作为申请信息发送至车站子云，申请加入系 统网络。

其中的线路信息、车站信息为本地基本信息，硬件信息属于能力信息(具体在后文进行介绍)；网络连接信息主要包括：连接IP地址、端口、连接用户名、密码等。

步骤S3、车站子云验证行车控制单元申请信息中的网络连接信息，包括连接信息有 效性、以及登录认证信息有效性；认证通过后，车站子云登记记录行车控制单元的申请信息。

步骤S4、车站子云转发行车控制单元的申请信息至中心公有云。

步骤S5、中心公有云登记行车控制单元信息，并根据其申请信息、突发事件与边缘监测节点关联规则、边缘监测节点监控区域和行车控制单元的位置，为行车控制单元分 配订阅主题。

本发明实施例中，单一边缘监测节点只监测单一事件，单一车站接收若干个边缘监 测节点提供的服务。例如，风事件，车站所处范围，可能有多个边缘监测节点提供风事件监测服务。车站单元加入网络时，可能订阅风事件、雨事件、停供电事件等。对风事 件，中心公有云存储提供风事件服务的边缘监测节点的信息，比如风事件由 F1/F2/F3/F4/F5/F6/F7等边缘监测节点提供服务，雨事件由Y1/Y2/Y3...../Y8节点提供服 务。那车站所处位置，关联有F1、F2、Y6、Y8，后续就由这4个节点对车站提供服务。 风事件与边缘监测节点F1-F7，雨事件与边缘监测节点Y1-Y8的对应关系，即为文中所述 的突发事件与边缘监测节点关联规则。

步骤S6、中心公有云将订阅主题信息通过车站子云，转发至行车控制单元。

步骤S7、行车控制单元接收订阅主题信息并保存。

步骤S8、本步骤与步骤S6同步，中心公有云将相应行车控制单元加入信息通知关联 的边缘监测节点，通知消息中包含行车控制单元的连接方式。

步骤S9、边缘子云转发中心公有云下发的行车控制单元加入通知至相应边缘监测节 点。

步骤S10、边缘监测节点向新加入的行车控制单元申请该其专有数据。

步骤S11、行车控制单元自身或通过车站子云，响应边缘监测节点请求，向其发送专 有数据，包括车站特殊需求、事件监测特殊需求以及所在线路车站特有的突发事件安全卡控策略。

如之前所述此处所涉及的“特殊需求”、“特有”等要求都是基于车站行车需求来设定的，可以从车站所处位置以及车站行车场景两个方面来考虑。

步骤S12、边缘监测节点采集、处理数据，产生的加工数据由边缘子云持续转发至行 车控制单元。

步骤S13、行车控制单元根据加工数据，并结合本地列车运营状态，持续进行行车调 度和安全卡控业务操作。

进一步的，为提高系统可靠性和性能，考虑从以下几点优化完善：

1)车站行车控制单元直接参与行车调度和安全卡控，车站行车单元实行主备双机热 备方式运行。

2)中心云服务器采用应用集群等分布式一致性数据库方式保存服务注册表信息和节 点信息。

3)车站子云缓存管辖范围内车站行车控制单元的专有安全卡控策略，由车站子云统 一对外提供线路内被请求车站的专有策略。

4)边缘子云缓存管辖范围内边缘监测节点的服务实例列表，由边缘子云统一对外提 供监控范围内被请求节点提供服务的服务实例列表。

5)车站行车控制单元和车站子云间、边缘监测节点和边缘子云间，建立心跳机制。由相应子云更新、存储辖内终端状态。

3、数据处理方式。

边缘子云内部，包括边缘监测节点，实行基于场景和事件的数据采集/打包方案。

单一边缘监测节点只关注和监测单一类型突发事件。由于业务的专一性，边缘监测 节点业务内聚性强，业务层级及业务逻辑清晰，实现简单，处理效率高。由传感器采集的原始数据，边缘监测节点初始加工，并依据内置的突发事件处置规则产生规整化后的 加工数据。

中心公有云执行接收数据的拆包、解析、入库和数据调度指挥工作。车站子云或车站行车控制单元执行接收数据的拆包、解析和使用工作。

数据拆包：发送方(如边缘监测节点)的数据组包操作和接收方(如中心公有云)的数据拆包操作互为逆操作。由于智能行车调度系统中事件类别、监测数据类别等多样 且不统一，本发明使用开发技术中的反射机制和静态协议转换表，提高项目开发代码优 雅性和项目开发效率。

数据解析：数据解析涉及数据传输协议和传输格式。本发明按照指定协议(具体协议内容在后文进行介绍)进行数据传输；数据格式方面，较为常用的格式包括XML和 JSON。本发明实施例中采用XML的数据传输格式。

数据调度：中心公有云并不直接参与边缘监测节点的数据分发和传输工作，而是通 过综合节点、事件和数据类型建立的调度规则以及规则分发，指挥边缘监测节点数据分发业务。

数据使用：对边缘监测节点传输数据，主要是加工数据，行车控制单元可直接或较为快速用于行车安全卡控业务操作。中心公有云则可延时将其用于数据挖掘以及安全卡控规则的自学习和迭代更新操作。

本发明实施例中，在数据运转、传输过程中，可以采用各类通用、专用的加解密算法，对数据进 行加解密操作。具体算法的选择，以算法安全等级和算法处理效率为综合考量。

三、通信机制。

通信机制主要从三个部分来进行介绍：数据传输协议、通信连接方式、消息传输移动窗口技术。

1、数据传输协议。

在网络边缘侧，数据流向如图6所示，主要说明可参见前文针对边缘监测节点的介绍。

网络边缘监测节点的数据传输层负责对原始数据和加工数据进行打包操作，通过基 于数据类型、事件类型和运营场景的不同连接方式，将数据传送至边缘监测节点所归属的边缘子云。边缘监测节点与边缘子云间数据传输协议表1所示，主要包括：协议头、数 据描述部分、以及数据；其中，数据描述部分包括：数据版本、数据ID、标识数据类 型、数据生成的具体时间、事件信息、全局唯一的边缘子云ID、边缘监测节点ID、压缩 标志位、以及附属信息。

表1数据传输协议

本发明实施例提出的数据传输协议主要用于系统中原始数据和加工数据的传输。基 于上述数据传输协议，本发明还提供一种消息时间有效性检查机制，以解决不稳定的网络通道质量导致时间敏感的突发事件处理数据失效的问题，该机制主要是通过合理的数据ID设计，实现消息时间有效性检查功能，具体方法如下：

表1中数据ID字段为基于SnowFlake算法原理设计的32位递增数值：数值高12位为由 边缘子云ID和边缘监测节点ID组合构造的消息发送终端标识值；低20位为发送方发送数 据时的瞬时时间戳；

车站子云维护所有边缘监测节点发送的最后时间戳信息；当其接收到即时消息，对 即时消息中的数据ID进行时间有效性检查：所述即时消息为当前时刻的消息，包括：原始数据与加工数据；

1)即时消息中数据ID的时间戳小于本地同一发送端的最后时间戳，且差值大于阈值 时，直接抛弃该即时消息；

2)即时消息中数据ID的时间戳大于本地同一发送端的最后时间戳，接收并处理该即 时消息，同步更新即时消息中的时间戳为本地最后时间戳；

3)其他情况下，接收并处理该消息，但不更新本地时间戳。

如之前所述，上述数据传输协议是用于系统中原始数据和加工数据的传输；当边缘 监测节点和边缘子云两者之间传输数据时，发送端即为边缘节点。当数据由边缘子云中转，由边缘子云发送给车站子云或中心公有云时，发送端即为边缘子云。

2、通信连接方式。

依据应用场景、传输数据量、数据时间敏感程度等，基于云边协同的高速铁路智能行车调度安全卡控系统各部分之间通过长短连接进行数据传输。

其中，长连接是指网络两侧建立连接之后，连接通道持续有效，即使是设定时间范围内数据传输完成之后，网络连接仍不中断；短连接是指在设定时间范围内数据传输完 成之后，中断网络连接。

长连接适用于大数据量、高频次、长时段场景下的数据持续传输，以网络资源保持为代价，降低了频繁的链接请求和断开请求开销；短连接适用于短时段内数据集中传 输，其连接状态较强的特定数据传输目的。

图7示出了各部分的通信连接方式。

作为统筹调度中心和系统指挥中枢，中心公有云具有对外传输数据集中、外联终端 数量大等特点。针对通用/专用数据转发、模块动态加入等场景，中心公有云对外以短连接的方式交互数据。针对边缘子云上传的大量突发事件原始监控数据，中心公有云与边 缘子云间建立长连接。

车站子云内部，由于局域网网络环境稳定可靠，车站子云与行车控制单元间建立长 连接用于数据传输和状态监控。

边缘监测节点与边缘子云间保持两条连接通道，长连接通道用于原始数据的延迟传 输，短连接通道用于加工数据的实时传输。

其他数据量小、时间集中的应用场景，采用短连接方式。

3、消息传输移动窗口技术。

为保证消息的有效传输，在边缘监测节点的传输层，针对原始消息和加工消息，分别引入不同窗口长度的消息窗口。

图8为消息窗口示例，每一方槽代表一包传输消息。按构造时间顺序，传输消息依次 加入消息队列队尾(图8横轴左侧为队头，右侧为队尾)。定义Pd为指向已发送成功消息的指针，Pu为指向下一待发送消息的指针；指针Pd和Pu之间消息槽范围为消息传输移动 窗口；基于消息窗口实现的消息有效传输技术流程如图9所示，主要包括：

步骤S1、读取配置，初始化消息队列和指针Pd与Pu，使指针Pd和Pu皆指向消息队列的队首。

步骤S2、将原始数据或者加工数据插入各自的消息队列，持续监控消息队列，当存在新的待发送数据时，转步骤S3。

本发明实施例中，加工数据和原始数据，分别有自己的消息队列；不同消息队列互不影响；加工数据一般是实时发送，原始数据一般是空闲时，延迟发送。

考虑到数据的发送和确认过程，有可能是比较耗时的，因此，需要持续监控消息队列，以判断是否存在新的待发送数据。具体来说：数据的发送和确认过程中，需要接收 对方的回执，才认定发送端发送成功；需要监控发送端发送逻辑，确认发送逻辑执行完 整，才认定发送端发送成功，从而存在“待发送的数据”可能与“已确认发送成功的数 据”之间，存在间隔。

示例性的，T1时刻，要发送A、B、C、D、E，5包数据，先发送A，最后发送E，Pu 指向队首A(Pu为指向下一待发送消息的指针)，Pd指向A的前一个虚拟地址(定义Pd 为指向已发送成功消息的指针)。T2时刻，发送A(未确认)，Pu指向B，Pd不变。T3 时刻，发送B(未确认)，Pu指向C。T4时刻，A确认，Pd指向A。此时，Pd和Pu之间， 相隔了BC。T5时刻，发送C，Pu指向D，Pd和Pu之间，相隔了BCD。当有新数据F插入 队列时，转步骤S3。

步骤S3、判断当前是否已达最大消息窗口，即指针Pu和Pd差值是否已达阈值；当已达最大发送窗口时，转步骤S4；否则，转步骤S7。

步骤S4、在已达最大消息窗口下，判断当前待发送消息对应突发事件状态对行车安 全的影响程度；在故障导向安全机制下，当事件影响程度加重时(如有电变无电、设备正常变设备故障等)，转步骤S5；否则，转步骤S6。

步骤S5、此种状态代表消息队列已满，边缘监测节点的数据传输层报警提示申请人 工介入且不再发送新的消息。

步骤S6、此种状态代表已发送、未确认数据对行车安全无影响，跳过中间数据的确认过程，直接发送新的数据；置指针Pd＝Pu，即跳过窗口中的数据确认过程，转步骤 S7。

步骤S7、发送步骤S2中新的待发送数据，并将指针Pu右移。

步骤S8、监控指针Pd指针指向数据的发送结果，当数据发送成功时，转步骤S9；否则，转步骤S2，进入下一消息发送逻辑。

步骤S9、更新指针Pd右移，窗口缩小。

通过上述流程描述可以看出，指针Pu始终指向下一待发送数据地址；指针Pd小于等 于Pu，即传输窗口大于等于空且不超过S3中使用的最大窗口阈值。

本发明实施例上述方案，主要获得如下有益效果：

1)借助云边架构设计以及边缘计算学习、卡控策略优化和信任安全认证等技术，充 分挖掘和利用大量智能化前端边缘监测节点的计算资源、存储资源和网络资源，减少节点资源浪费，提升高速铁路大数据环境下智能行车调度数据的计算效能、传输效能、网 络效能和应用效能

2)通过将计算和智能推向更接近实际的前端，改进传统系统在多源异构数据处理方 面的问题，减少车站行车控制单元数据处理压力，使其更集中精力于行车安全卡控业务处理；与此同时，缩减中心化和集中式处理规模，弱化中心云服务器耦合焦点程度，减 轻数据集中处理压力，使其专注统筹调度和流程掌控。

3)通过方案服务安全和数据安全设计，解决前端节点加入网络过程中的认证问题和 安全问题，提升高速铁路智能行车调度大数据安全；具体体现为：采用边缘监测节点服务能力认证、消息时间有效性检查、消息传输移动窗口和节点最后遗嘱等机制和方法， 统筹协调保证云边协同架构下的系统服务安全和数据安全。

4)层级化和解耦式的模块(系统各个部分可以理解为各个模块)设计加速工程开发 进度，降低工程维护成本；多协议栈配置提升系统扩展能力；分散的数据和资源解决资源集中和故障集中问题。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以 通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一 个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得 一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施 例所述的方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模 块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分 功能。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替 换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的 保护范围为准。