CN112612904A - 基于知识图谱的轨道交通应急方法及装置 - Google Patents

Abstract

本申请实施例中提供了一种基于知识图谱的轨道交通应急方法及装置，该方法包括：接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

Description

基于知识图谱的轨道交通应急方法及装置

技术领域

本申请涉及轨道交通运营技术领域，具体地，涉及一种基于知识图谱的轨道交通应急方法及装置。

背景技术

轨道交通行业的包含大量、复杂、专业的领域知识，例如轨道交通设备，软件系统，人员角色职责，物料物资等，通常，在轨道交通的运行中，随时可能出现突发情况，例如设备出现故障，在出现突发情况时，需要工作人员及时给出应急方案以维持轨道交通的正常运行。

通常，工作人员通常不具备轨道交通行业的所有的知识，通常需要联合多个专业人员，对出现的突发情况进行分析，以给出对应的应急方案。然而，这种方式会浪费大量的人力物力，难以及时给出应急方案以维持轨道交通的正常运行。

发明内容

本申请实施例中提供了一种基于知识图谱的轨道交通应急方法，装置，电子设备及存储介质，可以有效解决在轨道交通的运行遇到突发情况时，难以及时给出应急方案的问题。

根据本申请实施例的第一个方面，提供了一种基于知识图谱的轨道交通应急方法，该方法包括：接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；输出所述应急方案。

根据本申请实施例的第二个方面，提供了一种基于知识图谱的轨道交通应急装置，该装置包括：指令接收模块，用于接收应急处理指令；解析模块，用于解析所述应急处理指令，提取设备标识、设备参数为关键字信息；应急模块，用于基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；输出模块，用于输出所述应急方案。

根据本申请实施例的第三个方面，提供了一种电子设备，该电子设备包括一个或多个处理器；存储器；一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于执行如上述应用于电子设备的方法。

根据本申请实施例的第四方面，本申请实施列提供一种计算机可读存储介质，所述计算机可读存储介质中存储有程序代码，其中，在所述程序代码运行时执行上述的方法。

采用本申请实施例中提供的基于知识图谱的轨道交通应急方法，接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，在出现突发情况时，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一个实施例提供的基于知识图谱的轨道交通应急方法的流程图；

图2为本申请另一个实施例提供的基于知识图谱的轨道交通应急方法的流程图；

图3为本申请一个实施例提供基于微服务架构构建知识图谱的示意图。

图4为在图2所提供的实施例的基础上提供的基于知识图谱的轨道交通应急方法中部分步骤的流程图。

图5为本申请一个实施例提供的基于知识图谱的轨道交通应急装置的功能模块图；

图6为本申请实施例提出的用于执行根据本申请实施例的基于知识图谱的轨道交通应急方法的电子设备的结构框图。

具体实施方式

轨道交通行业的包含大量、复杂、专业的领域知识，例如轨道交通设备，软件系统，人员角色职责，物料物资等，通常，在轨道交通的运行中，随时可能出现突发情况，例如设备出现故障，在出现突发情况时，需要工作人员及时给出应急方案以维持轨道交通的正常运行。

通常，工作人员通常不具备轨道交通行业的所有的知识，通常需要联合多个专业人员，对出现的突发情况进行分析，以给出对应的应急方案。然而，这种方式会浪费大量的人力物力，难以及时给出应急方案以维持轨道交通的正常运行。

针对上述问题，本申请实施例中提供了一种基于知识图谱的轨道交通应急方法，接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

本申请实施例中的方案可以采用各种计算机语言实现，例如，面向对象的程序设计语言Java和直译式脚本语言JavaScript，以及Python等。

为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

请参阅图1，本申请实施例提供了一种基于知识图谱的轨道交通应急方法，具体的该方法可以包括以下步骤。

步骤110，接收应急处理指令。

在轨道交通的运行中，通常有专门的工作人员对轨道交通中运行的车辆进行调度。所述应急处理指令可以是指调车指令，所述工作人员可以通过对应的控制设备输入应急处理指令，实现对所述车辆的调配。车辆在运行中，容易出现突发情况，导致车辆难以正常运行，例如，在车辆出现故障，或轨道上出现异物，都会对车辆的正常运行带来影响。为了确保车辆的正常运行，尽快的运输乘客，可以通过下发应急处理指令，实现对车辆的调配。在本申请实施例中，以突发情况为设备出现故障为例进行详细说明。

所述应急处理指令中包括调配的设备标识以及设备参数。例如，增加3个车辆，车辆即为设备标识，设备参数为增加3个。工作人员可以下发应急处理指令，以应对突发情况，因此，可以获取到工作人员输入所述应急处理指令。

步骤120，解析所述应急处理指令，提取设备标识、设备参数为关键字信息。

在得到所述应急处理指令之后，可以对所述应急处理指令进行解析，提取设备标识和设备参数。在轨道交通领域中，所述应急处理指令可以是一段专用代码，因此，可以将所述专用代码转换为应急语句，所述应急语句为自然语句。如前举例中，所述应急语句可以是“增加3个车辆”，其中，“增加3个”为所述设备参数，“车辆”为所述设备标识。在得到应急语句后，可以对所述应急语句进行分词处理，得到设备标识和设备参数，具体的，可以是预先设置有对应的分词规则，按照所述分词规则对所述应急语句进行处理，得到设备标识和设备参数。

步骤130，基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案。

知识图谱(Knowledge Graph)是一种通过将应用数学、图形学、信息可视化技术、信息科学等学科的理论与方法与计量学引文分析、共现分析等方法结合，并利用可视化的图谱形象地展示学科的核心结构、发展历史、前沿领域以及整体知识架构达到多学科融合目的的现代理论。知识图谱用可视化技术描述知识资源及其载体，挖掘、分析、构建、绘制和显示知识及它们之间的相互联系，为信息推荐、语义理解、问题回答等提供支持。

所述知识图谱为微服务组件构建得到，在轨道交通应急处理中，所述知识图谱包括设备标识，设备参数以及应急方案的之间的关联关系。那么，以所述设备标识和设备参数为查询条件，在所述知识图谱中查询，可以得到对应的应急方案。

基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案之前，可以预先构建所述知识图谱。具体的，在构建知识图谱时，可以是通过微服务组件构建所述知识图谱。从而，在构建完成所述知识图谱时，可以基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案。

步骤140，输出所述应急方案。

将基于所述知识图谱得到应急方案输出，其中，所述应急方案可以包括对故障的描述，故障影响程度的分析，以及产生的效果，具体的，所述应急方案中的内容可以根据实际的需要进行设置，在此不做限定。从而，根据所述应急方案，工作人员可以确定是否下发该应急处理指令。

例如，在车辆出现故障，不能正常运行，会导致乘客滞留较多，因此，需要缩短车辆的运行间隔，加快运输乘客。此时，可以接收到工作人员输入的应急处理指令A，基于知识图谱得到应急方案A进行输出，此时工作人员查看应急方案A，发现会加长车辆的运行间隔。再次输入应急处理指令B，基于知识图谱得到应急方案B进行输出，此时工作人员查看应急方案B，发现会缩短车辆的运行间隔。从而工作人员可以直接下发应急处理指令B，实现缩短车辆的运行间隔，从而通过所述知识图谱可以辅助工作人员及时确定应急处理方案，以及时应对突发情况。

需要说明的是，本申请实施例提供基于知识图谱的轨道交通应急方法可以集成为控制设备的一个功能，也可以是作为电子设备上的一个应用程序，或是网页等。

本申请实施例提供的基于知识图谱的轨道交通应急方法，接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

请参阅图2，本申请另一实施例提供了一种基于知识图谱的轨道交通应急方法，在前述实施例的基础上重点描述了通过微服务附件构建知识图谱的过程，具体的该方法可包括以下步骤。

步骤210，接收应急处理指令。

步骤220，解析所述应急处理指令，提取设备标识、设备参数为关键字信息。

步骤210可参照前述实施例对应部分，在此不再赘述。

步骤230，通过多个微服务组件构建所述知识图谱。

在通过多个微服务组件构建所述知识图谱时，可以是实时采集源数据，所述源数据包括引起故障的设备标识，设备参数，以及故障原因；通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因；通过信息融合微服务对所述源数据进行合并以及消歧处理；通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，并将所述应急方案形成所述知识图谱。

设备标识是指轨道交通领域实际存在的客观主体的标识，可以是人员、设备、某种数据、某种场景的名称等，设备参数是指对设备的描述，可以是数据量、人员工作量、状态值等，故障原因是指是设备标识指代的设备和设备参数之间的关联关系，可以是人员直接的管理关系、设备之间的故障传导等。

可参阅图3，示出了基于微服务架构构建知识图谱的示意图。该架构包括IaaS层、PaaS层、SaaS层、网关层及接入层。其中，IaaS层用于实时采集不同类型的源数据并将采集到的数据存储至数据库中。

采集到的源数据的类型可以是结构化数据、半结构化数据及非结构化数据，所述源数据可以包括引起故障的设备标识，设备参数以及故障原因。

更具体的，采集的源数据的内容可以包括日常的行车系统日志、运行图信息、信号系统控制指令、客流数据、设备维护数据、人员排班计划、危险源数据、组织机构数据、应急值守数据、设备监测数据、数字化的应急预案数据、数字化的法律法规数据、模拟演练数据、内部救援资源数据、外部救援资源数据、应急处置过程记录数据、信息报送记录数据、历史案例数据、事故评估数据、数字化的技术资料数据等，以及地理信息、与系统相关的系统操作日志数据、突发事件发生现场图片数据、视频数据、应急预案、法律法规、技术资料、应急通话音频数据等。上述源数据的内容可以根据实际的需要进行设置，在此不做具体限定。

PaaS层用于提供一个统一的API接口规范，以使SaaS层中的各个微服务组件能够通过API接口访问数据库中的源数据，SaaS层用于通过多个微服务组件对源数据进行处理，获得知识图谱。

网关层用于提供知识图谱和外部互联网之间的通信通道，同时还用于管理知识图谱对外提供服务的API接口，接入层用于访问知识图谱，即包括多个能够访问到知识图谱的电子设备。

微服务(或微服务架构)是一种云原生架构方法，微服务架构中的单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成，与大型，紧密耦合的应用程序的整体方法相反。这些服务通常有自己的堆栈，包括数据库和数据模型；通过REST API接口、事件流或消息代理的组合相互通信。微服务架构具有高内聚、低耦合、易扩展(水平扩展和垂直扩展)、快速开发测试部署、能快速响应用户需求的特性，从而基于所述微服务架构，可以降低软件内部各个模块之间的耦合度，提升知识图谱应用后续的扩展性。

下面将对基于所述多个微服务组件构建知识图谱进行详细说明。请参阅图4，示出了通过所述微服务组件构建所述知识图谱的流程图。

步骤231，实时采集源数据，所述源数据包括引起故障的设备对应的设备标识，设备参数，以及故障原因。

如前所述，IaaS层用于实时采集不同结构形式的源数据，并将采集到所述源数据存储至数据库中。该部分可参照前述对应的描述，在此不再赘述。在本申请实施例中，采集的源数据主要是设备标识，设备参数，以及故障原因。

步骤232，通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因。

实时采集到所述源数据之后，可以通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因。

具体的，所述信息抽取微服务包括实体抽取微服务，属性抽取微服务以及关系抽取微服务。通过所述实体抽取微服务抽取所述源数据中的设备标识；通过所述属性抽取微服务抽取所述源数据中的设备参数；通过所述关系抽取微服务抽取所述源数据中的故障原因。

例如，源数据为51号道岔发生卡阻故障，初步判断是轨道夹石子导致，需要工班人员前往维修，51号道岔属于折返道岔，将导致线路上列车出现1小时晚点。通过实体抽取微服务得到的设备标识可以是“道岔”、“轨道”、“石子”、“列车”，通过属性抽取微服务得到的设备参数可以是“折返道岔”、“卡阻故障”，通过关系抽取微服务得到故障原因可以是“夹”，即“夹”可以视为“道岔”和“石子”的关系，是“石子”与“轨道”发生关联关系后，导致的“卡阻故障”。

在抽取所述源数据中的设备标识，设备参数，以及故障原因后，还可以对抽取的信息进行向量化操作，便于后续处理。

步骤233，通过信息融合微服务对所述源数据进行合并以及消歧处理。

在抽取得到源数据中的设备标识，设备参数，以及故障原因后，可以通信息融合微服务对所述源数据进行合并。可以是通过知识融合微服务合并从各个渠道采集到的源数据。还可以是将第三方知识库中的数据与所述源数据进行合并，丰富构建所述知识图谱的数据基础。

也就是说，在采集源数据时，可以是通过多个渠道采集到的，例如，在采集设备时，采集渠道可以是轨道交通的运营中心，也可以是售票中心，因此，可以将各个渠道采集源数据进行合并。

此时，所述源数据为合并后的数据，通过信息抽取微服务得到了设备标识，设备参数和故障原因。可以通过所述实体消歧微服务明确所述设备标识的含义，通过所述共指解析微服务对所述设备标识进行统一，得到消歧处理后的源数据。

通过实体消歧微服务明确设备标识的含义，通常同一个东西在不同的领域可能具有不同的含义，例如，苹果可以是指一家高科技公司，也可以是指水果。因此，可以通过实体消歧微服务可以明确各个设备标识的具体含义。通过所述共指解析微服务对所述设备标识进行统一，同一个设备可以具有不同的设备标识。例如，小明非常喜欢他的书包，“小明”和“他”都是指向小明，所以“小明”和“他”之间有共指关系。从而通过共指解析微服务可以明确各个设备标识之间的共指关系。通过实体消歧微服务和共指解析微服务，可以明确各个设备标识的含义以及共指关系，得到消歧处理后的源数据。

步骤234，通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，形成所述知识图谱。

在得到消歧处理后源数据后，可以通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，形成所述知识图谱。

具体的，所述信息加工微服务组件还包括本体构建微服务、质量评估微服务及知识推理微服务。可以是通过所述本体构建微服务、所述质量评估微服务及所述知识推理微服务对消歧处理后的相关信息进行推导分析得到应急方案，从而可以形成设备标识，设备参数以及应急方案之间的关联关系，得到所述知识图谱。需要说明的是，所述故障原因可以不在所述知识图谱中，仅为构建所述知识图谱所需要的内容。

所述本体构建微服务可以构建出知识图谱的雏形，本体包含某个学科内的基本实体和实体之间的关系，是描述领域知识的通用概念模型，从而可以自动或手动的构建本体。也就是说，初步构建出了设备标识，设备参数之间的关联关系，在构建出所述知识图谱的雏形后，知识之间的关系存在残缺，因此可以通过知识推理微服务对知识图谱的知识进行补全得到应急方案。知识推理可以分为基于规则的推理，基于图的推理以及基于深度学习的推理，所述知识推理微服务可以通过上述任一个方式对知识图谱进行补全。

构建得到所述知识图谱后，可以通过质量评估微服务对知识的可信度进行量化，通过舍弃可信度较低的知识来保障知识图谱的质量。

在得到所述知识图谱后，可以根据实时采集的源数据实时对已经构建的知识图谱进行更新，可以是更新所述知识图谱中的设备标识，设备参数以及应急方案等。知识更新的方式可以是全面更新，增量更新，全面更新是根据更新后的全部数据重新构建知识图谱；增量更新是指以新增数据为输入，向已经构建的知识图谱中新增知识。具体的，知识更新的方式可以根据实际的需要进行选择，在此不不做限定。

步骤240，基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案。

步骤250，输出所述应急方案。

步骤240至步骤250可参照前述实施例对应部分，在此不再赘述。需要说明的是，步骤230可以在步骤220或步骤210之前执行。具体的执行顺序，可以根据实际的需要确定，在此不做具体限定。

本申请实施例提供的基于知识图谱的轨道交通应急方法，通过多个微服务构建知识图谱，并基于所述知识图谱得到对应的应急方案。通过为多个微服务组件构建知识图谱，利用微服务组件的高内聚、低耦合、易扩展的特性，可以降低知识图谱的各个模块之间的耦合度，从而提升知识图谱的相关应用后续的扩展性。此外，软件开发人员可以单独对某一个或某几个知识图谱模块进行开发和升级，不会对其他模块的运行造成影响，提升了知识图谱的相关应用的开发效率。

请参阅图5，本申请实施例提供了一种基于知识图谱的轨道交通应急装置300，所述基于知识图谱的轨道交通应急装置300包括指令接收模块310，解析模块320，应急模块330，输出模块340。所述指令接收模块310用于接收应急处理指令；所述解析模块320用于解析所述应急处理指令，提取设备标识、设备参数为关键字信息；所述应急模块330用于基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；所述输出模块340，用于输出所述应急方案。

进一步的，在基于知识图谱对所述应急处理指令进行分析，得到与所述应急处理指令对应的应急方案之前，所述应急模块330还用于通过多个微服务组件构建所述知识图谱。

进一步的，所述应急模块330还用于实时采集源数据，所述源数据包括引起故障的设备标识，设备参数，以及故障原因；通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因；通过信息融合微服务对所述源数据进行合并以及消歧处理；通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，并将所述应急方案形成所述知识图谱。

进一步的，所述信息抽取微服务包括实体抽取微服务，属性抽取微服务，关系抽取微服务，所述应急模块330还用于通过所述实体抽取微服务抽取所述源数据中的设备标识；通过所述属性抽取微服务抽取所述源数据中的设备参数；通过所述关系抽取微服务抽取所述源数据中的故障原因。

进一步的，所述信息融合微服务包括知识融合微服务，实体消歧微服务，共指解析微服务，所述应急模块330还用于通过所述知识融合微服务合并从各个渠道采集到的源数据，所述渠道包括轨道交通的运营中心以及售票中心；通过所述实体消歧微服务明确所述设备标识的含义，通过所述共指解析微服务对所述设备标识进行统一，得到消歧处理后的源数据。

进一步的，所述信息加工微服务组件还包括本体构建微服务、质量评估微服务及知识推理微服务，所述应急模块330还用于通过所述本体构建微服务、所述质量评估微服务及所述知识推理微服务对消歧处理后的相关信息进行推导分析得到应急方案，形成所述知识图谱。

进一步的，所述解析模块320还用于将所述应急处理指令转换为应急语句，所述应急语句包括设备标识和设备参数；对所述应急语句进行分词处理得到设备和设备参数。

本申请实施例提供的基于知识图谱的轨道交通应急装置，接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

要说明的是，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

请参阅图6，本申请实施例提供了一种电子设备的结构框图，该电子设备400包括处理器410以及存储器420以及一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器420中并被配置为由所述一个或多个处理器410执行，所述一个或多个程序配置用于执行上述基于知识图谱的轨道交通应急方法。

该电子设备400可以是智能手机、平板电脑、电子书等能够运行应用程序的终端设备，还可以是服务器。本申请中的电子设备400可以包括一个或多个如下部件：处理器410、存储器420、以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器420中并被配置为由一个或多个处理器410执行，一个或多个程序配置用于执行如前述方法实施例所描述的方法。

处理器410可以包括一个或者多个处理核。处理器410利用各种接口和线路连接整个电子设备400内的各个部分，通过运行或执行存储在存储器420内的指令、程序、代码集或指令集，以及调用存储在存储器420内的数据，执行电子设备400的各种功能和处理数据。可选地，处理器410可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器410可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器410中，单独通过一块通信芯片进行实现。

存储器420可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。存储器420可用于存储指令、程序、代码、代码集或指令集。存储器420可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备400在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

本申请实施例提供的电子设备，接收应急处理指令；解析所述应急处理指令，提取设备标识、设备参数为关键字信息；基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案；输出所述应急方案。解析所述应急处理指令得到关键字信息，利用关键字信息在所述知识图谱中查询，辅助给出对应的应急方案，从而，工作人员可以快速确定应急方案，以维持轨道交通的正常运行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种基于知识图谱的轨道交通应急方法，其特征在于，所述方法包括：

接收应急处理指令；

解析所述应急处理指令，提取设备标识、设备参数为关键字信息；

基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；

输出所述应急方案。

2.根据权利要求1所述的方法，其特征在于，在基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案之前，还包括：

通过多个微服务组件构建所述知识图谱。

3.根据权利要求2所述的方法，其特征在于，所述通过所述微服务组件构建所述知识图谱，包括：

实时采集源数据，所述源数据包括引起故障的设备标识，设备参数，以及故障原因；

通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因；

通过信息融合微服务对所述源数据进行合并以及消歧处理；

通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，并将所述应急方案，形成所述知识图谱。

4.根据权利要求3所述的方法，其特征在于，所述信息抽取微服务包括实体抽取微服务，属性抽取微服务以及关系抽取微服务，所述通过信息抽取微服务识别所述源数据中的设备标识，设备参数，以及故障原因，包括：

通过所述实体抽取微服务抽取所述源数据中的设备标识；

通过所述属性抽取微服务抽取所述源数据中的设备参数；

通过所述关系抽取微服务抽取所述源数据中的故障原因。

5.根据权利要求3所述的方法，其特征在于，所述信息融合微服务包括知识融合微服务，实体消歧微服务以及共指解析微服务，所述通过信息融合微服务对所述源数据进行合并，以及消歧处理，包括：

通过所述知识融合微服务合并从各个渠道采集到的源数据，所述渠道包括轨道交通的运营中心以及售票中心；

通过所述实体消歧微服务明确所述设备标识的含义，通过所述共指解析微服务对所述设备标识进行统一，得到消歧处理后的源数据。

6.根据权利要求3所述的方法，其特征在于，所述信息加工微服务组件还包括本体构建微服务、质量评估微服务及知识推理微服务，所述通过信息加工微服务对消歧处理后的源数据进行推导分析得到应急方案，形成所述知识图谱，包括：

通过所述本体构建微服务、所述质量评估微服务及所述知识推理微服务对消歧处理后的源数据进行推导分析得到应急方案，形成所述知识图谱。

7.根据权利要求1所述的方法，其特征在于，所述解析所述应急处理指令，提取设备标识、设备参数为关键字信息，包括：

将所述应急处理指令转换为应急语句，所述应急语句包括设备标识和设备参数；

对所述应急语句进行分词处理得到设备标识和设备参数。

8.一种基于知识图谱的应急处理装置，其特征在于，所述装置包括：

指令接收模块，用于接收应急处理指令；

解析模块，用于解析所述应急处理指令，提取设备标识、设备参数为关键字信息；

应急模块，用于基于所述关键字信息在所述知识图谱中查询，得到与所述关键字信息对应的应急方案，所述知识图谱为多个微服务组件构建，所述知识图谱包括设备标识、设备参数以及应急方案之间的关联关系；

输出模块，用于输出所述应急方案。

9.一种电子设备，其特征在于，所述电子设备包括：

一个或多个处理器；

存储器，与所述一个或多个处理器电连接；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个应用程序配置用于执行如权利要求1至7任一项所述的方法。

10.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有程序代码，所述程序代码可被处理器调用执行如权利要求1至7任一项所述的方法。

Images