Cloud-edge collaboration architecture of railway information system
-
摘要: 随着铁路信息系统业务量和数据量的日益增加，迫切需要探索一种新的架构，提升系统的自治能力和响应能力。文章结合铁路信息系统业务特点，提出了适用于铁路信息系统的云边协同体系架构，详细阐述了云边协同的技术体系和微服务、容器编排、边缘计算等关键技术，并介绍了其在铁路信息系统中的应用场景，可对云边协同技术在铁路领域的落地实施提供参考。Abstract: With the increasing traffic and data volume of railway information system, it is urgent to explore a new architecture to improve the autonomy and responsiveness of the system. Combining with the business characteristics of railway information system, this paper proposed a cloud-edge collaboration architecture suitable for railway information system, expounded in detail the technical system of cloud-edge collaboration and key technologies such as microservices, container orchestration and edge computing, and introduced its application scenarios in railway information systems. It can provided a reference for the implementation of cloud edge collaboration technology in the railway field.
-
轨旁安全平台是卡斯柯公司全自主研发、通过SIL4级欧标认证的一种通用安全计算机系统[1]，采用2乘2取2架构，具有可靠性和安全性高、易于扩展等优点。目前，基于轨旁安全平台开发的轨道交通信号产品有区域控制器、线路控制器、无线闭塞中心等，已成功应用于多个轨道交通项目。
使用轨旁安全平台开发的信号产品在交付现场前，产品研发人员需要完成产品相关配置数据的设置，检查软件版本是否符合要求。当这些信号产品在现场开通运行后，可能会因设备中安装的下位机软件模块运行异常、硬件组件（如风扇、U盘等）状态劣化等导致信号系统异常，甚至是宕机，影响轨道交通正常运营。同时，由于轨道交通运营方能够安排的设备故障排查时间较短，给现场故障排查带来很大的困难，有些故障需要配合实验室内长时间的数据分析和调试才能复现和确认。
为此，亟需开发一套能够检测轨旁安全平台主要硬件组件和软件模块运行状态的维护用工具软件—维护检测子系统[2-3]，能够方便产品研发人员完成信号产品交付，帮助运行维护（简称：运维）人员采集信号产品现场运行数据，提供常见故障检测功能，快速、高效地分析数据和排查设备故障。
1 轨旁安全平台简介
轨旁安全平台由主处理子系统（MPS）、通用网关子系统（GGW）、冗余网络、维护检测子系统、电源等组成，如图1所示。
（1）MPS是平台的核心子系统，采用双机热备配置，有MPS-A、MPS-B两套独立设备（即A和B两个系别），每套设备配备有散热用风扇（即风扇A和风扇B）和用于装载配置数据与镜像文件的U盘。MPS运行负责安全通信数据的收发与处理的下位机软件模块，同时运行不同种类信号产品（如区域控制器等）的上层应用程序（App），这些应用程序采用统一接口与平台集成在一起。
（2）GGW负责内外网间数据转发，有GGW-A和GGW-B两套独立设备（即A和B两个系别），每套设备中安装有下位机软件模块。
（3）维护检测子系统运行在专用工控机上，通过冗余网络与MPS、GGW进行通信，负责将MPS和GGW中下位机软件模块的运行状态、MPS的风扇、U盘等硬件组件的健康状态以及网络连接状态记录在日志文件中，提供平台配置、运行监控、实时报警、日志导出等功能的人机界面。
（4）冗余网络是平台内部的冗余通信网络，有红网和蓝网两套网络设备，分别连接MPS、GGW、维护检测子系统，为平台各子系统提供高可靠的数据传输服务，如图2所示。
2 架构设计
维护检测子系统基于Spring.net框架[4]的模型—视图—控制器（MVC，Model View Controller）[5]设计模式，使用C#编程语言开发。维护检测子系统的功能模块在处理逻辑上划分为3层：通信层、数据处理层和视图层，如图3所示。
2.1 通信层
通信层主要是数据通信模块，负责发送和接收报文，并将报文存储在本地硬盘中。收发和存储的报文主要有3类：
（1）设备数据报文，维护检测子系统使用多通道用户数据报协议（MUDP，Multi User Datagram Protocol）与MPS和GGW设备进行通信，用于获取下位机软件模块的运行状态数据；（2）硬件物理接口报文，维护检测子系统使用简单网络管理协议（SNMP，Simple Network Management Protocol）[6-7]与MPS和GGW设备进行通信，用于获取网络连接状态数据；（3）风扇数据报文，维护检测子系统使用超文本传输协议（HTTP，Hypertext Transfer Protocol）协议与MPS的风扇进行通信。
2.2 数据处理层
数据处理层主要是报文解析模块，根据协议解析通信层定期采集的多协议报文，并将解析结果转发至视图层的各个界面。
2.3 视图层
视图层包括平台主界面和1个或多个上层应用定制界面。平台主界面用于查看监控数据，实时显示报警信息，提供数据查询与分析功能。上层应用定制界面可根据信号产品的个性化需求，由开发人员基于统一接口进行定制开发。
3 功能设计
3.1 配置数据设置
产品研发人员完成各类配置数据的录入和设置，包括报警码对照表、软件版本信息、通信配置项、参数阈值、日志管理信息、界面信息等，并将这些数据保存在配置文件中。
（1）报警码对照表录入：录入平台下位机软件模块相关报警码对照表信息，保存在报警码配置文件中，供实时报警模块用于解析报警信息，包括设备名、下位机软件模块名、报警码、报警描述、报警类型、报警等级、维护提示。此外，考虑到不同信号产品上层应用对平台的差异化需求，可将与具体信号产品无关的报警码信息项设置为被忽略，使实时报警界面不显示对应的报警码信息。
（2）版本信息设置：依据具体信号产品软件版本检查单，设置MPS、GGW设备中各下位机软件模块版本号，包括设备名、下位机软件模块名、版本名称、版本号，将版本信息保存在配置文件中。
（3）通信配置项设置：在设备配置文件中配置平台内每套设备（包括MPS-A、MPS-B、GGW-A、GGW-B）的红网和蓝网IP地址、端口号、设备标识（报文中区分不同设备的标识），确保红、蓝网IP地址在不同的两个网段中；配置风扇A和风扇B的IP地址和最大超时时间；配置设备发出的报文类型、消息队列和对应的报文解析实例名。
（4）参数阈值设置：根据经验设置风扇、U盘的相关性能参数阈值，如风扇的最大温度、最小温度、最大转速、最小转速、U盘最低读写速度等；这些参数阈值保存在设备配置文件中，可根据信号产品不同的应用环境和系统架构调整这些参数阈值[8]，作为判断风扇、U盘状态的依据。
（5）日志管理设置：设置生成和管理日志文件的相关信息并保存在日志配置文件中，主要包括各类日志文件的路径和名称、日志记录追加方式、保留期限（默认3个月）、单个日志文件大小上限（默认10 M）；设置日志记录最低等级，系统运行日志的日志记录分为DEBUG、INFO、WARN、ERROR 4个等级，默认为INFO，日志记录等级比该设置项低的不被写入系统运行日志文件中。
（6）界面显示设置：设置用户界面显示相关的信息并保存在界面配置文件中，包括主界面、上层应用定制界面的实例名、子系统自身版本号等。
3.2 软件版本比对
现场运维人员对现场信号产品中MPS、GGW设备各下位机软件模块进行软件版本比对，检查所安装的下位机软件模块是否与软件版本检查单相符。
（1）版本查询请求：现场运维人员在操作界面上显示的设备列表中选择部分或全部设备，点击“请求”按钮，子系统向这些设备上运行的下位机软件模块发送版本查询请求报文。
（2）版本显示：子系统接收下位机软件模块回复的版本查询结果报文，并与从配置文件中读取的各设备下位机软件模块版本信息进行比对，在界面上显示版本查询结果列表，版本比对不一致的软件模块所属设备以高亮显示。
3.3 数据采集与状态监控
子系统通过红、蓝网分别与平台其他子系统进行通信，实时采集各子系统运行数据并判断其状态，在主界面上显示和动态刷新设备运行状态。
（1）数据采集与状态判别：持续获取MPS和GGW设备中下位机软件模块的运行状态数据；定期检测网络连接状态，动态检查网络断开或连接状态；定期采集风扇设备的转速、温度和电压信息，并据此判断风扇健康状态。
（2）MPS/GGW设备状态监控：现场运维人员在平台主界面上选择设备系别，显示该设备的名称及其红蓝网IP地址、MPS设备的主备状态及下位机软件模块持续运行时间，每隔1 s实时刷新设备状态；动态显示GGW转发的内外网数据、GGW设备中下位机软件模块的运行情况。
（3）MPS风扇状态监控：现场运维人员在平台主界面上选择风扇设备系别，显示设备名称和IP地址，以列表形式实时显示风扇电压、温度和转速。
（4）网络状态监控：主界面上显示平台内部网络拓扑示意图，以红色、蓝色线段分别代表红网、蓝网，MPS和GGW两系设备图元与红蓝网间连接线以是否闪烁表示连接状态是正常、异常或未知；在线段上悬浮或单击时显示相连的两个设备名称，在设备图元上悬浮或点击时显示设备名称，方便现场运维人员观察网络连接状态是否正常。
3.4 实时报警
子系统对监测数据进行分析，根据预定义的参数阈值、报警码对照表，自动判断报警，显示在主界面下方的报警信息列表中，包括报警时间、报警码、报警设备、报警描述、报警等级及维护提示。
（1）软件模块报警：报警信息列表中实时滚动刷新各设备的下位机软件模块的报警报文，提醒现场运维人员根据报警等级和维护提示及时处理。
（2）U盘报警：系统自动判断MPS设备中当前使用的U盘是否正常，当U盘出现异常，在报警信息列表中提示维护人员及时进行维护。
（3）风扇报警：系统自动根据风扇的关键参数判断并产生报警信息，界面中对应设备以红色底色高亮显示，并显示在报警信息列表中，现场运维人员可根据报警等级和维护提示采取应急处理措施。
3.5 日志记录
子系统将接收到原始报文和解析后的报文内容、以及平台各组件的运行状态生成相应的日志文件，保存在工控机本地硬盘中，方便产品研发人员进行调试和故障分析。
（1）原始报文日志记录：子系统接收到报文后，随即以二进制文件形式将其存储在本机硬盘固定路径下，避免原始报文在解析的过程中出现异常导致数据无法保存；原始报文日志文件以设备名和日期时间命名。
（2）解析报文日志记录：子系统将解析后的报文以明文形式存储在固定路径下，按设备名称划分文件夹，文件夹下日志文件按日期和时间命名。
（3）系统运行日志记录：主要记录子系统的运行动态，包括启动时间、处理报文条数和处理时长，与设备的网络连接的状态变化情况，以便于产品研发人员分析现场信号设备运行中出现的问题。
3.6 日志导出
当现场发生问题后，现场运维人员根据实际情况查找并导出相关日志文件，供产品研发人员用于问题分析和故障排查。
（1）解析报文日志查找与导出：针对现场问题，以日期和时间、设备、系别（A机或B机）为关键字查找解析报文日志，并将查找到的所有日志文件以压缩包形式导出至指定路径，供产品研发人员分析和定位问题。
（2）运行日志及配置文件导出：现场运维人员将运行日志文件及所有配置文件一并导出到指定路径下，供产品研发人员准确分析现场问题。
3.7 U盘检测
检测连接到工控机USB接口上用于装载配置数据和镜像文件的U盘读写功能是否正常，若检测失败，提示失败的原因。
4 关键技术
4.1 用户界面灵活扩展与多协议支持
考虑到轨旁安全平台可用于开发多种轨道交通信号产品，维护检测子系统的用户界面应能支持多种上层应用（对应于不同的信号产品）的配置管理和维护需求，允许上层应用采用不同的通信协议。
如图4所示，可通过在用户界面框架中增加子窗口的方式，将不同上层应用的定制界面作为插件加入其中，实现用户界面的灵活扩展，且不同的上层应用可采用不同的数据通信协议与维护检测子系统进行交互。
针对上层应用开发定制界面时，在界面配置文件中定义上层应用定制界面的对象实例及相关配置信息，如区域控制器定制界面实例名定义为appControl，如图5所示，即可在工程中编写相关的类文件程序。当程序启动时，从应用程序入口处进入dmShell主界面，遍历加载界面配置文件中controlList中的各个界面窗口。
目前，维护检测子系统支持SNMP、MUDP、HTTP通信协议，可通过增加报文处理类来扩展对其他类型通信协议的支持。例如，某个新开发信号产品的上层应用要求支持TFTPS协议，可以在通信层添加TFTPS协议报文接收类，在数据处理层添加TFTPS消息队列和TFTPS报文解析类。
4.2 多协议报文解析
有的轨道交通线路可能是7×24 h不间断运营，子系统应能持续、可靠地接收和处理下位机软件模块定期发送的报文，报文发送周期为毫秒级，要求子系统具有较高的报文接收和处理速度。
为此，采用生产者—消费者设计模式，使报文接收和报文解析处理逻辑完全解耦，利用消息队列（MQ，Message Queue）机制作为生产者与消费者之间的共享数据缓冲区，实现报文接收线程与报文解析处理线程之间异步通信，提高报文数据处理效率和稳定性，如图6所示。
（1）报文接收：子系统分别使用SNMP协议和HTTP协议，以轮询方式向风扇设备和网络设备发送状态请求报文，将回复报文放入相应的消息队列中。使用MUDP协议接收MPS和GGW设备定时发送的下位机软件模块的运行状态报文，接收的运行状态报文经红蓝网过滤机制去重后，经过CRC（Cyclic Redundancy Check）完整性校验后，将报文写入MUDP消息队列中；受限于MUDP报文长度，当一次传输内容较多时，MPS和GGW设备会将传输内容拆分成多条报文来发送；对于长度超过最大传输单元（MTU，定义为1300字节）类型的MUDP报文，数据处理层根据报文中主周期号（即下位机软件模块的运行周期号，一个32字节整数）、报文总包数、报文包序列号3个参数，对这些分包发送的报文进行组包操作，将其重组为一条完整的报文。
（2）报文解析：消息队列与报文解析类一一对应，每个解析类处理一种类型的报文。先定义报文解析基类，指定解析时间和返回解析后字符串的方法；其他解析类继承该基类，并定义该类报文特有的解析方法和属性。
（3）解析结果分发：报文解析后返回的字符串放入消息队列中，分发给对应的界面展示线程和日志存储线程。界面展示线程读取消息队列中返回的字符串内容，以每隔1 s的频率在界面上实时刷新或滚动显示；日志存储线程将返回的字符串以明文方式写入存储在本地日志文件中。
4.3 日志生成
根据现场信号系统问题数据分析需求，将运行情况和接收的报文信息分类生成日志。为了更好地管理和查询各类日志数据，采用日志分级和轮转存储策略，根据用途和记录信息的重要性，将日志文件划分为3种主要类别：系统运行日志、解析报文日志、原始报文日志，分别保存在指定的路径下，以不同格式记录在工控机本地硬盘中。
（1）系统运行日志：子系统启动后开始自动记录运行日志，每条运行日志记录都带有时间戳，方便产品研发人员追溯现场问题发生过程。日志记录按照重要性和用途划分为4个等级，具体定义如表1所示。通过在配置管理模块中设置日志记录最低等级，可以控制系统运行日志记录的记录内容。通常，运行在现场的子系统默认的日志记录等级为INFO，即不记录DEBUG等级的日志记录，只有当需要利用日志数据分析系统性能或调试时才将子系统的日志等级设置为最低等级DEBUG。
表 1 日志记录等级定义日志记录等级 分级依据 日志记录示例 DEBUG 反映子系统状态、性能的统计类信息 数据处理的条数、处理时长、发送和接收报文的IP等简单信息等，可表征子系统的处理能力、负载等性能 INFO 反映设备关键信息的
状态变化系统设备变化状态、网络连接状态变化等，用于分析信号设备的关键信息 WARN 子系统运行主日志 如子系统启动时间、查询操作、版本查询操作等，主要用于分析用户行为和操作步骤，可帮助定位系统问题 ERROR 子系统关键功能发生
异常文件读写错误、解析异常处理、数据采集线程异常等，用于分析子系统本身问题和定位通信协议错误问题 （2）解析报文日志：子系统将解析后的报文以明文方式记录在解析报文日志文件中，便于产品研发人员理解报文内容和进行深入分析。解析报文日志文件采取多文件持久化存储策略，保存在按设备名称系别、日期创建的子文件夹中，方便日志文件检索。当正在写入的日志文件达到单个文件大小上限后，先关闭当前日志文件，接着自动创建新的日志文件继续记录，新文件名称包含序列号，以区分相同类型的日志文件。
（3）原始报文日志：子系统在报文接收监听线程接收到原始报文后，立即以二进制的格式保存在工控机本地硬盘的原始报文日志文件中，确保能够正确地还原为原始格式，用于产品研发人员通过报文重放复现和分析现场问题。
子系统在运行过程中持续不断生成日志文件，考虑工控机硬盘的容量限制，采取日志轮转策略，定期删除老旧日志。按照先进先出（FIFO，First In First Out）原则，只保留设置期限内的日志文件，老旧日志文件自动删除，及时释放工控机磁盘空间。
5 结束语
维护检测子系统作为轨旁安全平台配套的维护用工具软件，具有配置灵活、易于扩展的特点。提供运行状态监控和实时报警功能，便于现场运维人员掌握设备运行情况，快速排查故障和采取针对性处理措施；具备完善的日志记录与便捷的日志导出功能，提高了现场信号系统运行数据采集效率，便于产品研发人员追溯现场问题发生过程，精准定位故障。其软件架构采用MVC设计模式，将数据采集报文的接收、解析与界面显示逻辑相分离，程序易于维护、扩展性强，可根据信号产品的个性化需求灵活定制用户界面，以及增加对新协议的支持。
基于轨旁安全平台开发的信号产品已应用于多个轨道交通项目中，操作简便的维护检测子系统为这些现场信号系统的稳定运行起到支撑作用。此外，在实验室内信号产品的测试或调试过程中，也可使用该工具软件来查看下位机软件模块运行状态，分析运行中出现的问题。
-
[1] Surbiryala J, Rong C. Cloud computing: History and overview[C]//2019 IEEE Cloud Summit, August 8-10, 2019, Washington, DC, USA. New York, USA: IEEE, 2019: 1-7.
[2] 施巍松,张星洲,王一帆,等. 边缘计算: 现状与展望 [J]. 计算机研究与发展,2019,56(1):69-89. DOI: 10.7544/issn1000-1239.2019.20180760 [3] 林 刚. 基于大数据云计算的铁路智能运维系统技术研究 [J]. 铁道通信信号,2019,55(5):37-41. DOI: 10.13879/j.issn1000-7458.2019-05.19049 [4] 陈玉平,刘 波,林伟伟,等. 云边协同综述 [J]. 计算机科学,2021,48(3):259-268. [5] Yue Z, Zhu Z, Wang C, et al. Research on Big Data Processing Model of Edge-Cloud Collaboration in Cyber Physical Systems[C]// 2020 5th IEEE International Conference on Big Data Analytics (ICBDA), May 8-11, 2020, Xiamen, China. New York, USA: IEEE, 2020: 140 - 144.
[6] Wamser F, Lombardo C, Vassilakis C, et al. Orchestration and monitoring in fog computing for personal edge cloud service support[C]//2018 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), June 25-27, 2018, Washington DC, USA. New York, USA: IEEE, 2018: 91-96.
[7] 朱建军,方琰崴. 面向服务的5G云原生核心网及关键技术研究 [J]. 数字通信世界,2018(2):111. DOI: 10.3969/J.ISSN.1672-7274.2018.02.084 [8] 曹文潇,马 军. 基于云计算的铁路智能平台的研究和实现 [J]. 现代工业经济和信息化,2019,9(10):65-66. DOI: 10.16525/j.cnki.14-1362/n.2019.10.27 [9] Zhang K, Huang W, X Hou, et al. A Fault Diagnosis and Visualization Method for High-Speed Train Based on Edge and Cloud Collaboration [J]. Applied Sciences, 2021, 11(3): 1251. DOI: 10.3390/app11031251
[10] Singh D, Banyal R K, Sharma A K. Cloud computing research issues, challenges, and future directions[M]//Emerging Trends in Expert Applications and Security. Berlin, Germany: Springer, 2019: 617-623.
[11] Tang G, Guo D, Wu K, et al. QoS guaranteed edge cloud resource provisioning for vehicle fleets [J]. IEEE Transactions on Vehicular Technology, 2020, 69(6): 5889-5900. DOI: 10.1109/TVT.2020.2987839
[12] Newman S. Building microservices[M]. Sevastopol, California, USA: O'Reilly Media, Inc.. 2021.
[13] 靳 磊. 微服务在铁路调度管理系统改造中的应用 [J]. 铁路计算机应用,2017,26(4):43-47. DOI: 10.3969/j.issn.1005-8451.2017.04.011 [14] Casalicchio E. Container orchestration: a survey[M]. Systems Modeling: Methodologies and Tools. Berlin, Germany: Springer, 2019: 221-235.
[15] Kosińska J, Zieliński K. Autonomic management framework for cloud-native applications [J]. Journal of Grid Computing, 2020, 18(4): 779-796. DOI: 10.1007/s10723-020-09532-0
[16] Cao K, Liu Y, Meng G, et al. An overview on edge computing research [J]. IEEE access, 2020(8): 85714-85728. DOI: 10.1109/ACCESS.2020.2991734
[17] 涂文靖,杨 飞,曲建军,刘秀波. 铁路工电供检测监测技术现状与发展探讨 [J]. 铁路技术创新,2021(6):1-5. DOI: 10.19550/j.issn.1672-061x.2021.06.001 [18] 李明春,王 威,倪西冰. 边缘计算在铁路行业的应用和价值 [J]. 信息通信技术,2020,14(4):37-44,64. DOI: 10.3969/j.issn.1674-1285.2020.04.006
下载:
计量
- 文章访问数: 212
- HTML全文浏览量: 101
- PDF下载量: 78
