基于知识模型的城轨信号故障诊断系统

杨 将，阳亦斌，欧盛芬，邓永祁

（湖南中车时代通信信号有限公司，湖南 长沙 410005）

0 引言

近年来，我国城市轨道交通（简称“城轨”）运营规模迅速扩大，对城轨设备的RAMS技术（即可靠性、可用性、可维修性和安全性）不断造成挑战。2020年3月，中国城市轨道交通协会发布了《中国城市轨道交通智慧城轨发展纲要》，其明确指出智能运维安全体系为智慧城轨建设蓝图中八大体系的重要组成部分之一。智能运维安全体系中的信号系统运维安全属于运营安全的重点内容［1］。一方面，城轨的运营线路、在建线路和规划线路规模屡创新高，信号设备和设施分散、数量大、种类多，使得线路运维需求快速增长，需要更多专业的信号系统运维人员。另一方面，信号设备运维人员的专业能力需要长时间的知识和经验积累，否则无法快速合理地处置城轨信号系统故障，对线路的安全运营会产生重大影响［2］。此外，城轨信号系统的故障种类繁多，诊断分析逻辑复杂，当前国内外主要厂商采用针对不同场景的故障设计诊断程序的方式，使得故障诊断系统的代码冗余且开发周期永无止境。为此，本文采用网络本体语言，抽取和描述信号系统故障诊断的分析逻辑，建立知识模型；并基于知识模型，设计城轨信号故障诊断系统。该系统作为城轨信号智能运维安全体系的关键部分，通过知识模型对信号系统运行数据进行智能推理，从而实现自动故障诊断。

1 基于知识模型的城轨信号故障诊断系统架构

基于知识模型的城轨信号故障诊断系统架构分为数据采集层、数据平台层和应用平台层3层（图1）。

图1 基于知识模型的城轨信号故障诊断系统架构示意图Fig.1 Architecture of the urban rail signal fault diagnosis system based on knowledge model

数据采集层主要采用数据接入程序和数据解析程序完成信号子系统设备运行数据的采集，其包括车载控制系统（vehicle on board control，VOBC）、联锁系统（computer interlocking，CI）、区域控制系统（zone controller，ZC）、应答器系统、数据传输网管系统（data communication system，DCS）、列车自动监控系统（automatic train supervision，ATS）、计轴、道岔、转辙机、外电网、信号机、电源系统及数据管理系统（data manage system，DMS）等。

数据平台层采用典型的Lambda架构和Hadoop技术生态圈相关技术，通过消息中间件接收来自数据采集层的数据，在大数据集群中完成数据的实时和离线处理。数据处理模块在接收到故障报警数据后，根据所建的故障知识模型和设备运行数据来实时诊断故障原因，并将故障诊断的结果实时推送给应用平台。数据处理模块主要涉及的技术组件有：消息中间件、Spark、Sparkstreaming、Hbase、Hive、Hdfs、缓存及关系型数据库等。

系统应用平台采用基于SpringCloud的微服务技术架构。为提高效率，设备运行数据采用周期传输的采集方式，故障报警数据采用事件触发的采集方式。

系统的知识模型主要包括故障诊断知识模型和故障诊断过程模型。基于信号系统、故障诊断知识模型和故障诊断过程模型的流程设计如图2所示。数据接入软件根据信号子系统的具体工程通信协议框架，将所采集的信号子系统数据传输到消息队列中，数据解析程序根据工程码位表对信号子系统数据进行解析并传入Spark。系统初始化时，Spark从关系型数据库读出故障诊断知识模型和故障诊断过程模型的配置。Spark完成模型初始化后，实时进行故障诊断分析，并将分析结果存储到关系型数据库和缓存中。微服务平台从缓存中读取故障诊断分析结果，由WebSocket实时推送到应用系统前端。

图2 基于知识模型的城轨信号故障诊断流程设计图Fig.2 Design diagram of the urban rail signal fault diagnosis process based on knowledge model

2 城轨信号故障诊断知识模型

城轨信号故障诊断系统的组成部分主要包括故障诊断的知识模型以及故障诊断过程分析模型。本体语言在工业互联网领域中作为概念与知识模型的形式化规范说明已经得到行业广泛应用。其中，网络本体语言（ontology web language，OWL）的子语言 OWL DL（description logic）除了能描述知识模型外，还具备在推理系统中实现最大程度表达的能力，并且推理系统能够在有限的时间内完成全过程计算［3］。城轨信号系统设备的故障诊断分析逻辑非常复杂，为了能够实现信号系统故障诊断的完全推理，本文采用OWL DL进行知识建模：抽取和描述信号系统故障诊断的分析逻辑并建立知识模型，利用系统设备运行状态信息匹配故障原因，完成从信号系统设备状态空间到故障原因空间的映射，实现信号系统设备故障自诊断。

2.1 故障诊断知识建模

城市轨道交通信号系统设备的故障诊断知识建模包括故障诊断知识创建、故障诊断知识映射和故障诊断知识获取。

（1）故障诊断知识创建

城轨信号系统设备在运行时会产生大量的实时运行数据，而不同信号子系统设备的数据格式与数据采集方式存在较大差异。为此，构建故障诊断核心本体，通过抽取信号系统设备故障诊断的表达信息，将数据描述为系统可读的形式，实现故障诊断知识的创建。

（2）故障诊断知识映射

通过建立完备的知识模型，通用化地描述所有城轨信号系统设备的故障诊断实体及其相互关系，以完成城轨信号系统设备的故障诊断知识映射［4］。故障诊断分析数据模型的建立主要通过分析现有故障诊断分析运维手册文档和历史故障案例、从信号系统运维专家或者设计专家处获取的专家知识经验来实现［5］。故障诊断分析数据模型的建立，主要通过对故障诊断分析涉及的主要概念、关键字、特定类型数据进行专门标识并提取和分析这些概念之间的重要关系来实现［6］。

（3）故障诊断知识获取

知识获取是将信号系统设备信息语义化，也就是把信号系统设备信息转化成知识，这些知识能够在后续故障诊断分析中重复传递［7］。本体将各信号子系统设备的知识进行汇聚，便于统一地处理语义化的知识［8］。

信号系统故障诊断知识具有异构多源的结构，其特性具有较大的不确定性，不仅需要状态监测数据，又与运维参与者和系统设计者的经验思维有关。因此，若要实现故障诊断知识的表示、推理与反馈，就需要求知识管理方法系统、全面。本文阐述的本体驱动的信号系统故障诊断分析知识建模过程如图3所示，其基本流程主要表现：（1）过滤故障诊断分析任务的相关信息，以此建立可描述的知识模型；（2）根据实际运维经验与所设计的故障诊断方法，建立信号系统运行状态与故障原因之间的映射。

图3 故障诊断知识建模示意Fig.3 Schematic diagram of the fault diagnosis knowledge modeling

完备清晰地整理城轨信号系统领域的核心概念是故障诊断知识建模的首要任务，也就是构造可扩展的故障诊断分析语义层次（核心本体）。核心本体主要完成对分析对象、分析行为、实体关系和分析方法论的定义，并对分析对象、行为以及实体之间的相互关系进行定义［9-11］。核心本体主要包括设备域本体（DeviceDomain）、数据域本体（DataDomain）、分析域本体（AnalyseDomain）和诊断域本体（DiagDomain），这些核心本体分别对设备实体、状态、故障诊断、诊断过程、诊断决策的抽象概念以及相互关系进行定义和描述，层次结构如表1所示。

表1 故障诊断语义核心本体的层次划分和作用Tab.1 Hierarchy division and function of fault diagnosis semantic core ontology

2.2 故障诊断语义知识的关联

故障诊断知识模型中的领域概念知识之间关系复杂，图4展示了故障诊断模型中的概念、模型位置、作用及其从属关系。故障诊断分析过程（AnalyseProcess）细分为若干故障诊断分析步骤（AnalyseStep），主要涉及步骤所执行的条件（Condition）、故障原因（FaultReason）与故障本身之间的相互关系。设备条件（Condition）语义描述较为复杂，分解为5个子类：DeviceOfState、ComponentOfState、DeviceOfCommand、DeviceOfLogstate与 DeviceOfAnaStepState，分别与设备状态（State）、控制命令（Command）、逻辑状态（LogState）及故障原因类相关联。故障诊断本体框架中主要概念关系的含义如表2所示。

表2 故障诊断本体框架的主要概念关系Tab.2 Main conceptual relationships of the fault diagnosis ontology framework

图4 故障诊断本体知识关系示意Fig.4 Schematic diagram of knowledge relationship of the fault diagnosis ontologies

2.3 故障诊断过程建模

故障诊断知识建模是城轨信号系统故障诊断的基础，本节基于知识模型的核心本体进行信号系统故障诊断分析过程建模，对故障诊断分析过程的数据和流程实现语义化并进行抽取，将分析过程描述为基于状态变迁的一系列执行步骤。系统采用决策树来执行故障诊断分析过程。将故障诊断分析过程分解为执行条件、故障诊断分析步骤和分析结果3部分。只有在作为执行条件的分析步骤状态满足要求时，故障诊断分析步骤才会执行，并产生分析结果。这一系列执行条件、分析步骤和分析结果组成故障诊断过程模型，如图5所示。其中，故障诊断分析步骤状态的逻辑表达结果为False时，故障诊断分析过程进入下一个分析步骤；逻辑表达结果为True时，执行故障诊断分析步骤，得出分析结果，最后结束诊断。

图5 故障诊断过程示意图Fig.5 Schematic diagram of the fault diagnosis process

分解后的诊断分析基本元素一一对应于分析域本体中的类和关联，整个诊断分析可以看作是一系列分析步骤（AnalyseStep）的实例集合，每一步骤包含多个分析步骤状态（DeviceOfAnaStepState）。

3 系统应用

该故障诊断系统被部署在控制中心机房，主要包括通信服务器、应用服务器、数据服务器和交换机等，系统结构示意如图6所示。按照系统架构的3层设计，数据采集层由通信服务器实现，数据平台层由数据服务器集群实现，应用平台层由应用服务器实现。

图6 系统组成示意Fig.6 Schematic diagram of the system composition

通信服务器主要完成实现本系统与信号子系统的数据接口，获取信号子系统设备数据。应用服务器提供web应用服务，满足系统的应用服务功能。数据服务器集群构成大数据平台，用于存储故障知识模型和故障诊断数据。万兆交换机满足服务器大数据集群的需求，同时与维护网通信。

由于基于信号系统的知识建模工作繁杂，因此本文以列车移动授权（movement authority，MA）回撤的异常诊断为例，建立知识模型和故障诊断过程模型。如图7所示，根据ZC与CI系统采集数据，建立知识模型，包括ZC与CI系统设备域和数据域的设备状态（State）、部件（Component）、控制命令（Command）、逻辑状态（LogState）。

图7 知识建模示意Fig.7 Schematic representation of the knowledge modeling

根据图7中的知识模型进一步建立分析域和诊断域的知识模型，并建立列车回撤故障诊断过程模型，如图8所示。系统同时采集ZC、CI设备的状态、部件、控制命令和逻辑状态数据，因此系统基于知识模型和故障诊断过程模型快速诊断故障原因，辅助运维人员定位故障，通过工程应用能够有效降低运营安全事故率15%，提升故障处置效率20%。

图8 故障诊断过程建模示意Fig.8 Schematic diagram of the fault diagnosis process modeling

设备状态空间到故障原因空间的映射关系表现为运行状态与故障原因之间的本体映射（简称状态-故障原因映射）。状态-故障原因映射主要依靠设备类（Device）、部件类（Component）、状态类（State）、控制命令类（Command）、逻辑状态类（LogState）和条件类（Condition）及其间的相互关系来完成，具体算法如下：

4 结语

本文研发了一种基于知识模型的城轨信号故障诊断系统，以实现城轨各信号子系统间协同联动分析和故障诊断。该系统采用网络本体语言对信号系统故障诊断过程进行知识建模，从信号系统知识创建、知识映射、知识获取的维度完成知识模型的建立。基于知识模型构造可扩展的故障诊断核心本体，定义了分析对象、分析行为和实体关系，并进行故障诊断语义关联。基于知识模型的核心本体进行信号系统故障诊断分析过程建模，对故障诊断分析过程的数据和流程实现语义化并进行抽取，将分析过程描述为基于状态变迁的一系列执行步骤并采用决策树来执行分析过程。基于故障诊断知识模型、故障诊断过程模型开展应用设计，实现信号系统数据采集、数据分析以及分析结果推送的系统应用，为城轨信号系统运维管理提供决策支持，提升了运营和故障处置效率。

基于知识模型的城轨信号故障诊断系统可进行故障原因分析并向运维人员提供诊断结果，但由于故障处置往往涉及多部门，存在资源调度与处理时无法高效统筹执行等问题，这是城轨信号运维领域下一步亟须探讨与研究的课题。