CN116821798B - 一种故障预警的服务器、方法及计算机存储介质 - Google Patents

Abstract

本申请涉及汽车技术领域，尤其涉及一种故障预警的服务器、方法及计算机存储介质，用以实现高效准确的故障预警。其中，故障预警的服务器用于获取的待检测设备的故障消息，从故障消息中提取用于描述所述故障消息的目标消息类型的关键数据；确定目标消息类型对应的目标配置项，配置项用于描述需监控的所述待检测设备的故障要素；将关键数据与获取的目标配置项的配置数据合成待检测数据；获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。本申请通过针对不同消息类型设置不同的配置项以及校验规则，提高了故障预警的准确率以及处理效率。

Description

一种故障预警的服务器、方法及计算机存储介质

技术领域

本申请涉及汽车技术领域，尤其涉及一种故障预警的服务器、方法及计算机存储介质。

背景技术

当前，电动汽车在通过充电桩进行充电时，充电桩可能会出现故障、订单异常等情况，此时，如果相关运营人员无法及时感知，将导致充电桩在异常状态下持续运行，造成用户负面体验以及资源的浪费。

相关技术中，在充电桩出现异常情况时将异常信息上报至服务器，服务器在接收到异常信息后，仅针对异常信息进行一次整体的规则校验，确定出现设备故障时，获取充电桩的相关信息并进行故障上报，但该方式故障检测的准确率不高。

因而，如何实现高效准确的故障预警，成为亟待解决的问题。

发明内容

本申请实施例提供的一种故障预警的服务器、方法及计算机存储介质，用以实现高效准确的故障预警。

本申请实施例提供的一种故障预警的服务器，服务器包括处理器和存储器，其中，存储器存储有计算机程序，当计算机程序被处理器执行时，使得处理器执行如下步骤：

获取待检测设备的故障消息，并从故障消息中提取关键数据，关键数据用于描述故障消息的目标消息类型；

确定与目标消息类型对应的目标配置项，配置项用于描述需监控的待检测设备的故障要素；

获取目标配置项的配置数据，并将关键数据以及配置数据合成待检测数据；

获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。

在一些实现方式中，上述处理器执行的方法形成程序后，各个程序功能模块对应的硬件执行模块可包括：数据提取模块、配置项确定模块、数据合成模块以及故障校验模块：

数据提取模块，用于获取待检测设备的故障消息，并从故障消息中提取关键数据，关键数据用于描述故障消息的目标消息类型；

配置项确定模块，用于确定与目标消息类型对应的目标配置项，配置项用于描述需监控的待检测设备的故障要素；

数据合成模块，用于获取目标配置项的配置数据，并将关键数据以及配置数据合成待检测数据；

故障校验模块，用于获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。

本申请实施例提供的一种故障预警的方法，方法包括：

获取待检测设备的故障消息，并从故障消息中提取关键数据，关键数据用于描述故障消息的目标消息类型；

确定与目标消息类型对应的目标配置项，配置项用于描述需监控的待检测设备的故障要素；

获取目标配置项的配置数据，并将关键数据以及配置数据合成待检测数据；

获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。

本申请实施例中的一种计算机程序产品，包括计算机程序，当计算机程序被处理器执行时实现如上述任意一种故障预警的方法。

可选的，计算机可读存储介质可以作为计算机程序产品的一种实现，即本申请实施例还提供一种计算机可读存储介质，其包括计算机程序，当计算机程序被处理器执行时实现如上述任意一种故障预警的方法。

本申请实施例提供的一种电子设备，包括处理器和存储器，其中，存储器存储有计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任意一种故障预警的方法的步骤。

本申请有益效果如下：

本申请实施例提供了一种故障预警的服务器、方法及计算机程序产品。本申请中，并非是对待检测设备的故障消息进行一次整体的规则校验，而是先从故障消息中提取用于描述故障消息所属的目标消息类型的关键数据，基于该关联数据确定检测规则。具体的，本申请通过对不同类型的故障消息进行分类，针对不同消息类型设置不同的配置项以及校验规则，使消息规则匹配更精准；经过多次的筛查，提高了故障预警的准确率，且通过分类处理提高了故障消息的处理效率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为本申请实施例中的一种应用场景的一个可选的示意图；

图2为本申请实施例中的一种故障预警的方法的实施流程图；

图3为本申请实施例中的一种故障预警的过程的结构示意图；

图4为本申请实施例中的一种规则校验的过程的实施流程图；

图5为本申请实施例中的一种故障告警的过程的实施流程图；

图6为本申请实施例中的一种可能的记录文件的示意图；

图7为本申请实施例中的一种可能的告警通知的示意图；

图8为本申请实施例中的一种故障预警的设备的结构示意图；

图9为应用本申请实施例的一种电子设备的一个硬件组成结构示意图；

图10为应用本申请实施例的另一种电子设备的一个硬件组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

下面对本申请实施例中涉及的部分概念进行介绍。

充电桩：充电桩是指为电动汽车提供能量补充的充电装置，充电桩的输出端装有充电插头（即充电枪），用于为电动汽车充电。

Query Wrapper：是MyBatis-Plus框架提供的一种查询构建器，支持链式调用，但需要进行多次方法调用和对象创建，灵活性相对较低。

SQL（Structured Query Language，结构化查询语言）表达式：是指由SQL语言中的关键字、函数、运算符和常量等组成的一个表达式，用于描述SQL查询语句中的各种条件和计算。SQL表达式可以用于SELECT、WHERE、HAVING、ORDER BY等语句中，用于筛选、计算和排序数据。

规则校验：校验上报的故障消息是否符合预设校验规则，符合即作出相应处理。

MQ（Message Queue，消息队列）：是一种异步通信方式，用于在不同的应用程序之间传递消息，可以将消息存储在队列中，等待接收方来获取并处理这些消息。MQ消息通常具有以下特点：可靠性高、异步性、解耦性等。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图1所示，其为本申请实施例的应用场景示意图。该应用场景图中包括多个设备端110和服务器120。

在本申请实施例中，设备端110可以为充电桩，当检测到运行出现异常时，向服务器120上报故障消息。设备端110也可以为服务器，其在检测到存在异常订单时，向服务器120上报故障消息。

服务器120与多个设备端110相连接，接收多个设备端上报的故障消息，并对故障消息进行分析处理：通过消息来源、消息类型等属性进行消息的分类，基于故障消息对应的分类拉取对应的上下文信息，并根据对应的校验规则校验上下文信息是否满足规则，在满足规则的情况下触发消息告警，向关联对象发送消息提箱，并在需要有处理动作的情况下，执行相关处理动作。

服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（Content Delivery Network，CDN）、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一种可选的实施方式中，设备端110与服务器120之间可以通过通信网络进行通信。

在一种可选的实施方式中，通信网络是有线网络或无线网络。

需要说明的是，图1所示只是举例说明，实际上设备端的数量不受限制，在本申请实施例中不做具体限定。

下面结合上述描述的应用场景，参考附图来描述本申请示例性实施方式提供故障预警的方法，需要注意的是，上述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。

如图2所示，为本申请实施例提供的一种故障预警的方法的实施流程图，以执行主体为服务器为例，该方法的具体实施流程包括如下步骤S201~S204：

步骤S201，获取待检测设备的故障消息，并从故障消息中提取关键数据。

其中，关键数据用于描述故障消息的目标消息类型。

可选的，上述待处理设备即上述设备端110，当待检测设备检测到故障时，将故障消息存储在消息队列中，即消息队列中存储有：根据时间顺序检测到的待检测设备的至少一个故障消息。服务器从待检测设备的消息队列中，获取待检测设备的故障消息，在一些实施例中，服务器从待检测设备的消息队列中获取故障消息时，按照消息队列中故障消息的排列顺序（即时间顺序）依次获取，服务器每获取一个故障消息，即执行步骤S201-S204所述的故障预警过程。消息队列可在不同的应用程序之间传递消息，通过可以将消息存储在队列中，数据传输可靠性更高。

可选的，待检测设备的故障消息中携带有与消息类型相关的数据（即上述关键数据），在获取到待检测设备的故障消息后，从故障消息中提取关键数据，以便于后续执行与目标消息类型对应的处理流程。

需要说明的是，故障消息对应的消息类型可基于需求进行设置，本申请实施例不做限制，在一种可选的实施方式中，故障消息的消息类型可划分为设备消息、充电消息、运营消息、运维消息等。

本申请实施例中，由于服务器连接有多个设备端，因此待检测设备上报的故障消息的消息体结构并不统一，为便于后续处理，在从故障消息中提取关键数据后，将关键数据整合为规范结构，其中，规范结构为基于需求预先定义的，本申请实施例对其具体结构不做限制。

步骤S202，确定与目标消息类型对应的目标配置项；其中，配置项用于描述需监控的待检测设备的故障要素。

可选的，本申请实施例中预先设置消息类型与配置项的第一对应关系，并基于该第一对应关系，确定与目标消息类型对应的目标配置项。

本申请实施例中消息类型可以包括一个级别或多个级别，当消息类型仅包括一个级别时，则可以直接确定目标消息类型对应的目标配置项；当消息类型包括多个级别时，在每相邻两个级别中，下一级别的消息类型表示：对上一级别的消息类型进行划分得到的消息子类型；在每相邻两个级别中，下一级别的消息类型对应的配置项表示：对上一级别的消息类型对应的配置项集合进行划分得到的配置项子集合。此时，第一对应关系包括：各个级别的消息类型与配置项之间的对应关系。

本申请实施例中，对消息类型包括的级别的数量不做限制，可基于需求进行设置。在一种可选的实施方式中，消息类型包括两级。

例如，当故障消息的一级消息类型可划分为设备消息、充电消息、运营消息、运维消息，设备消息可进一步划分为二级消息类型（即一级消息类型的消息子类型）：离线、故障和混控，充电消息可进一步划分为二级消息类型：订单、计费等，运营消息可进一步划分为二级消息类型：配置异常、操作异常，运维消息可进一步划分为二级消息类型：不当操作等。

在实施中，可为不同的消息类型设置不同的编码，例如将设备消息的编码设定为1，充电消息的编码设定为2，运营消息的编码设定为3，运维消息的编码设定为4，进一步地，可将离线、故障和混控的编码设定为11、12和13。同时，本申请实施例中对各级消息类型对应的配置项的具体设置也不做限制，可基于需求进行设置。例如，当故障消息的类型为充电消息时，可设置其对应的配置项为故障的发生时间以及故障描述等。

具体地，当消息类型包括多个级别时，上述步骤S202具体包括步骤S2021~S2022（图2未示出）：

步骤S2021：按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的配置项集合中，确定与下一级消息类型对应的配置项子集合。

步骤S2022：将目标消息类型包含的最后一级消息类型对应的配置项子集合中的配置项，作为故障消息对应的目标配置项。

通过对消息类型进行分级，并逐级确定配置项子集合，能够精准地确定对应的配置项，便于后续规则校验以及故障告警，且避免了因配置项不准确导致后续重复查询数据库。

步骤S203，获取目标配置项的配置数据，并将关键数据以及配置数据合成待检测数据。

可选的，上述获取目标配置项的配置数据，包括如下至少一个步骤：

从故障消息中，提取目标配置项的第一配置数据；

从预存储的待检测设备的设备信息中，查询目标配置项的第二配置数据。

具体地，本申请实施例中可以预先存储与待检测设备相关的设备信息，例如，待检测设备的位置信息以及标识等。此外，故障消息中也携带有故障相关的信息，例如，故障的发生时间、故障编号以及故障描述等。在获取目标配置项的配置数据时，可从故障消息和/或设备信息中，获取目标配置项的配置数据。通过多种途径获取配置数据，保证了获取到的数据充分性。

本申请实施例中，通过在待检测数据中添加配置数据，即添加与待检测设备相关的信息，便于后续进行规则校验和告警消息组合发送使用，避免了执行规则校验以及生成告警消息时，频繁获取故障的相关数据导致的资源浪费。

步骤S204，获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。

可选的，本申请实施例中预先设置消息类型与校验规则的第二对应关系，并基于该第二对应关系，获取与目标消息类型对应的目标校验规则。

本申请实施例中消息类型可以包括一个级别或多个级别，当消息类型仅包括一个级别时，则可以直接确定目标消息类型对应的目标校验规则；当消息类型包括多个级别时，在每相邻两个级别中，下一级别的消息类型表示：对上一级别的消息类型进行划分得到的消息子类型；在每相邻两个级别中，下一级别的消息类型对应的校验规则表示：对上一级别的消息类型对应的检验规则集合进行划分得到的校验规则子集合。此时，上述第二对应关系包括：各个级别的消息类型与检验规则之间的对应关系。

本申请实施例中，对检验规则（子）集合中校验规则的具体设置不做限制，可基于需求进行设置。

具体地，当消息类型包括多个级别时，上述步骤S204具体包括步骤S2041~S2042（图2未示出）：

步骤S2041，按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的校验规则集合中，确定与目标消息类型包含的下一级消息类型对应的校验规则子集合；

步骤S2042，将目标消息类型包含的最后一级消息类型对应的校验规则子集合中的校验规则，作为与故障消息对应的目标校验规则。

通过对消息类型进行分级，并逐级确定校验规则子集合，使匹配到的校验规则更加准确，进而提高了故障预警的准确性。

在另一种可选的实施方式中，当上述步骤S202中消息类型包括多个级别，且第一对应关系包括：各个级别的消息类型与配置项之间的对应关系时，本申请实施例中还可以设定上述第二对应关系为消息类型对应的配置项与检验规则之间的关系，即预先针对最后一级消息类型对应的配置项设置其对应的校验规则集合，在确定与目标消息类型对应的目标配置项后，基于配置项与检验规则之间的关系，确定目标配置项对应的校验规则集合中的校验规则，作为目标校验规则。

以下表1为例，假设消息类型分为一级消息类型以及二级消息类型（二级消息类型对应的级别低于一级消息类型），待检测设备的目标消息类型中，一级消息类型为设备消息类型1，二级消息类型为设备故障消息11，且设置有配置项与检验规则之间的关系。

实施中，首先基于目标消息类型包含的一级消息类型（设备消息类型1），从整个配置项集合中确定与设备消息类型1对应的配置项集合1；然后，从配置项集合1中，确定与目标消息类型包含的二级消息类型（设备故障消息11）对应的配置项子集合2，并将配置项子集合2中的配置项，如设备故障恢复监控111等作为故障消息对应的目标配置项；然后，基于配置项子集合2，查找到对应的校验规则集合（如下表中的设备故障告警规则10001等），从中获取目标校验规则。

可选的，本申请实施例中上述目标校验规则中包括多个配置项的参考取值；若待检测数据中各配置项的实际取值与对应的参考取值一致，则确定待检测数据满足目标校验规则。

具体地，本申请实施例中校验规则采用SQL表达式的方式构建，相较于相关技术中使用的Query Wrapper，SQL表达式是一种比较成熟的校验方式，更易于操作，语言更容易理解，且能够保证***稳定；并且通过将SQL表达式构建的校验规则配置在数据库中，可以通过修改数据库修改校验规则，实现了灵活配置，减少了对代码的修改，同时，可以通过数据库直接增减校验规则。目前SQL校验支持多种表达式处理例如 =，and，in，like等。

可选的，本申请实施例在基于上述第二对应关系确定目标校验规则并进行动态校验之前，还需要对故障消息进行静态校验，具体地，从待检测设备的历史上报消息中查询目标消息类型的消息，若查询到目标消息类型的消息，且查询到的消息的数量达到设定阈值，则确定校验通过，执行后续确定目标校验规则的步骤；若未满足上述条件，则确定校验未通过，不再执行后续规则校验的步骤，即结束本次故障预警。进一步的，本申请实施例中还可以设置查询的历史上报消息对应的时间范围，例如设置在距离当前时间24小时内的历史上报消息中查询。

需要说明的是，本申请实施例对上述设定阈值的取值不做限定，可基于需求进行设置，例如，设定为3次。

可选的，上述触发故障预警时，执行如下至少一个步骤：

基于待检测数据生成用于记录待检测设备的故障情况的记录文件，并存储；具体地，记录文件中记载的具体数据本申请实施例不做限制，可基于需求进行配置，例如，设置记录文件中记录有故障的消息类型、目标校验规则、待检测设备的位置及编号、故障的描述等信息。

基于待检测数据生成告警通知，并向待检测设备的关联对象发送告警通知；其中，上述关联对象不限于待检测设备的使用者、操作者以及管理者，可基于需求进行配置。且告警通知中记载的具体数据以及发送方式本申请实施例不做限制，可基于需求进行配置，例如，设置告警通知中记录有待检测设备的位置及编号、目标校验规则、故障的发生时间以及故障的描述等信息；设置告警通知的发送方式为应用软件、短信以及电话等。

确定与故障类型对应的处理类型，并执行处理类型对应的处理操作；具体地，上述处理类型包括但不限于不处理、参数调整（即对待检测设备的运行参数进行调整）或者结束运行（即使待检测设备的结束运行）等，参数调整对应的处理操作包括但不限于发放工单、降低电流、降低功率以及设备重启等。本申请实施例中针对故障，不仅具备发现能力，还具备处理能力；通过在触发故障预警时，执行对应的处理操作，满足当前的业务需求，使整个处理过程更加完整。

上述方法，通过对不同类型的故障消息进行分类，针对不同消息类型设置不同的配置项以及校验规则，使消息规则匹配更精准；经过多次的筛查，提高了故障预警的准确率，且通过分类处理提高了故障消息的处理效率。

以下结合图3，以具体的示例对上述故障预警的过程进行详细阐述，如图3所示，故障预警的处理过程具体包括：

消息上报模块：其他服务需要监控的故障消息和设备（如充电桩）的故障消息通过MQ的方式上报至监控***（即本申请实施例中的服务器）。

在一种具体的实施方式中，待检测设备为充电桩，上报的故障消息中具体包括故障代码fault Code:“5028”、故障状态fault Stastus:“0”、充电枪标识gun ID:“3”、时间戳timestamp：“25377”、消息类型message Type:“charge Stub”、插座类型socket Type:“IOT”等。

消息分发模块：包括消息类型的判断、消息格式整理以及消息分发，具体地，监控平台中的消息分发模块，基于接收的故障消息确定对应的消息类型（即提取故障消息中的关键数据），并进行消息格式整理，将提取的数据整合成监控***能够处理的消息体，并基于消息类型分发到不同的告警处理器中，例如设备相关的消息会发送到设备处理器，分发到此处理的消息，会按照设备相关的参数进行规则处理；充电相关的消息会发送到充电处理器等。

在一种具体的实施方式中，进行消息格式整理后得到的消息体alert Message中具体包括：设备标识device ID:“10021100002573”、故障代码fault Code:“5028”、故障状态fault Stastus:“0” 、充电枪标识gun ID:“3”、消息类型（设备消息）msg Type:“1”、消息子类型（设备故障消息）msg Sub Type:“12”。

数据聚合模块：按照故障消息对应的消息类型的级别由高到低的顺序，依次从上一级消息类型对应的配置项集合中，确定与目标消息类型包含的下一级消息类型对应的配置项子集合，至查询到最后一级消息类型，经过多级筛查，确定精准的配置项，查找上下文消息获取相应的配置数据，并与关键数据聚合得到待检测数据，为后续规则校验做准备。例如，如果待检测设备上报了一条充电异常的故障消息，该模块将从故障消息中提取的配置数据以及从待检测设备的设备信息中提取的配置数据整合到一起，在一些实施例中，待检测设备的设备信息可以包括充电处理器最近收到的所有充电异常消息。

在一种具体的实施方式中，通过数据聚合可以增加许多与该设备相关的信息，例如场站信息station Info（包括待检测设备的位置信息、设备标识等），故障描述faultDesc:“充电中车辆控制导引故障（仅直流桩使用）”等，以便与后续规则校验和告警消息组合发送使用。

规则匹配模块：包括校验规则匹配以及校验规则获取，具体地，规则匹配模块根据消息类型，查找相匹配的校验规则集合，并获取校验规则集合中校验规则的配置信息。

在一种具体的实施方式中，通过规则匹配模块可以获取到故障消息对应的校验规则，该校验规则可以为一条或多条，例如，故障消息匹配到了两条校验规则，可以从规则配置中获取规则名称rule Name，规则表达式rule Exp，同时，该校验规则可以同时配置有对应的告警规则，例如告警消息发送模版msg Template，告警消息组group Id等。

规则校验模块：包括静态校验和动态校验，实施中，规则校验模块会首先进行初步的静态校验（即代码编码强校验），静态校验通过后，进行动态检验，即基于预先配置的SQL表达式（即目标校验规则）的校验，通过将SQL表达式和待校验数据进行组合匹配校验，校验通过后会触发后续告警处理。

在一种具体的实施方式中，静态校验的规则可以为：在数据库中24小时内查到三次记录则满足条件。

动态校验规则可以为：查找状态为场站状态station Info.status为在线（即1），且故障代码为“5028，5052，5054，5000”中任一；待检测设备中可以查找到stationInfo.status = 1且alert Message.fault Code =5028，则确定满足校验规则，校验通过，触发后续告警处理。

本申请实施例中，当通过上述规则匹配模块匹配到多项校验规则时，依次基于各项校验规则进行校验，具体步骤如图4所示，包括：

步骤S401，对待校验数据进行静态校验，确定校验是否通过；若结果为是，则执行步骤S402，若结果为否，则执行步骤S405；

步骤S402，基于当前的校验规则对待校验数据进行动态校验，确定校验是否通过，若结果为是，则执行步骤S403，若结果为否，则执行步骤S405；

步骤S403，触发报警；

步骤S404，确定当前校验规则是否为匹配到的多项校验规则中的最后一项，若是则执行步骤S405，若否则执行步骤S406；

步骤S405，结束处理；

步骤S406，将多项校验规则中的下一项校验规则作为当前的校验规则，并返回执行步骤S401。

告警处理模块：如图5所示，告警处理包括记录、告警以及动作处理。其中：

记录是指：基于待检测数据生成用于记录待检测设备的故障情况的记录文件，并存储，例如，在能源运营平台对相关问题做记录保留。图6为本申请实施例提供的一种可能的记录文件的示意图，如图6所示，记录文件中可以包括：故障消息的消息标识、消息类型、校验规则、消息内容（如故障代码、故障描述、待检测设备的设备标识、充电枪标识、故障的发生时间）、待检测设备的位置信息（如所属的场站名称）、车位编号、消息主体类型（如设备或订单等）。

告警是指：基于待检测数据生成告警通知，并向待检测设备的关联对象发送告警通知，以便于关联对象收到告警通知后执行对应的处理。图7为本申请实施例提供的一种可能的告警通知的示意图，如图7所示，告警通知中可以包括待检测设备的位置信息（如所属的场站名称）、故障代码、故障描述、待检测设备的设备标识、充电枪标识、故障的发生时间、车位编号等。

动作处理是指：确定与故障类型对应的处理类型，并执行处理类型对应的处理操作，例如将正在充电的订单直接关闭订单。

基于相同的发明构思，本申请实施例提供的一种故障预警的服务器，包括：处理器和存储器；其中，所述存储器与所述处理器连接，所述存储器用于存储计算机程序；所述处理器用于执行以下方法：

获取待检测设备的故障消息，并从所述故障消息中提取关键数据，所述关键数据用于描述所述故障消息的目标消息类型；

确定与目标消息类型对应的目标配置项，所述配置项用于描述需监控的所述待检测设备的故障要素；

获取所述目标配置项的配置数据，并将所述关键数据以及配置数据合成待检测数据；

获取与所述目标消息类型对应的目标校验规则，若所述待检测数据满足所述目标校验规则，则触发故障预警。

在一些实现方式中，上述处理器执行的方法形成程序后，各个程序功能模块对应的硬件执行模块可包括：数据提取模块、配置项确定模块、数据合成模块以及故障校验模块。

如图8所示，其为本申请实施例中的一种故障预警的设备800的组成结构示意图，该故障预警的设备包括数据提取模块801、配置项确定模块802、数据合成模块803以及故障校验模块804，其中：

数据提取模块801，用于获取待检测设备的故障消息，并从故障消息中提取关键数据，关键数据用于描述故障消息的目标消息类型；

配置项确定模块802，用于确定与目标消息类型对应的目标配置项，配置项用于描述需监控的待检测设备的故障要素；

数据合成模块803，用于获取目标配置项的配置数据，并将关键数据以及配置数据合成待检测数据；

故障校验模块804，用于获取与目标消息类型对应的目标校验规则，若待检测数据满足目标校验规则，则触发故障预警。

可选的，上述消息类型包括多个级别，在每相邻两个级别中，下一级别的消息类型表示：对上一级别的消息类型进行划分得到的消息子类型；在每相邻两个级别中，下一级别的消息类型对应的配置项表示：对上一级别的消息类型对应的配置项集合进行划分得到的配置项子集合；

配置项确定模块802，具体用于：

按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的配置项集合中，确定与下一级消息类型对应的配置项子集合；

将上述目标消息类型包含的最后一级消息类型对应的配置项子集合中的配置项，作为上述故障消息对应的目标配置项。

可选的，在每相邻两个级别中，下一级别的消息类型对应的校验规则表示：对上一级别的消息类型对应的检验规则集合进行划分得到的校验规则子集合；

故障校验模块804，具体用于：

按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的校验规则集合中，确定与上述目标消息类型包含的下一级消息类型对应的校验规则子集合；

将上述目标消息类型包含的最后一级消息类型，对应的校验规则子集合中的校验规则，作为与上述故障消息对应的目标校验规则。

可选的，上述目标校验规则中包括多个配置项的参考取值；若上述待检测数据中各配置项的实际取值与对应的参考取值一致，则确定上述待检测数据满足上述目标校验规则。

可选的，设备800还包括静态校验模块，故障校验模块804用于确定与目标消息类型对应的目标校验规则之前，静态校验模块用于：

确定从上述待检测设备的历史上报消息中，查询到上述目标消息类型的消息，且查询到的消息的数量达到设定阈值。

可选的，数据合成模块803获取上述目标配置项的配置数据，包括如下至少一个步骤：

从上述故障消息中，提取上述目标配置项的第一配置数据；

从预存储的上述待检测设备的设备信息中，查询上述目标配置项的第二配置数据。

可选的，故障校验模块804触发故障预警时，执行如下至少一个步骤：

基于上述待检测数据生成用于记录上述待检测设备的故障情况的记录文件，并存储；

基于上述待检测数据生成告警通知，并向上述待检测设备的关联对象发送上述告警通知；

确定与上述故障类型对应的处理类型，并执行上述处理类型对应的处理操作。

可选的，数据提取模块801具体用于：

依次从上述待检测设备的消息队列中，获取上述待检测设备的故障消息；其中，上述消息队列中存储有：根据时间顺序检测到的上述待检测设备的至少一个故障消息。

为了描述的方便，以上各部分按照功能划分为各模块（或单元）分别描述。当然，在实施本申请时可以把各模块（或单元）的功能在同一个或多个软件或硬件中实现。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为***、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“***”。

与上述方法实施例基于同一发明构思，本申请实施例中还提供了一种电子设备。在一种实施例中，该电子设备可以是服务器，如图1所示的服务器。在该实施例中，电子设备的结构可以如图9所示，包括存储器901，通讯模块903以及一个或多个处理器902。

存储器901，用于存储处理器902执行的计算机程序。存储器901可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。

存储器901可以是易失性存储器（volatile memory），例如随机存取存储器（random-access memory，RAM）；存储器901也可以是非易失性存储器（non-volatilememory），例如只读存储器，快闪存储器（flash memory），硬盘（hard disk drive，HDD）或固态硬盘（solid-state drive，SSD）；或者存储器901是能够用于携带或存储具有指令或数据结构形式的期望的计算机程序并能够由计算机存取的任何其他介质，但不限于此。存储器901可以是上述存储器的组合。

处理器902，可以包括一个或多个中央处理单元（central processing unit，CPU）或者为数字处理单元等等。处理器902，用于调用存储器901中存储的计算机程序时实现上述故障预警的方法。

通讯模块903用于与终端设备和其他服务器进行通信。

本申请实施例中不限定上述存储器901、通讯模块903和处理器902之间的具体连接介质。本申请实施例在图9中以存储器901和处理器902之间通过总线904连接，总线904在图9中以粗线描述，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线904可以分为地址总线、数据总线、控制总线等。为便于描述，图9中仅用一条粗线描述，但并不描述仅有一根总线或一种类型的总线。

存储器901中存储有计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于实现本申请实施例的故障预警的方法。处理器902用于执行上述的故障预警的方法，如图2所示。

下面参照图10来描述根据本申请的这种实施方式的计算装置1000。图10的计算装置1000仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图10，计算装置1000以通用计算装置的形式表现。计算装置1000的组件可以包括但不限于：上述至少一个处理单元1001、上述至少一个存储单元1002、连接不同***组件（包括存储单元1002和处理单元1001）的总线1003。

总线1003表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、***总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元1002可以包括易失性存储器形式的可读介质，例如随机存取存储器（RAM）1021和/或高速缓存存储器1022，还可以进一步包括只读存储器（ROM）1023。

存储单元1002还可以包括具有一组（至少一个）程序模块1024的程序/实用工具1025，这样的程序模块1024包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置1000也可以与一个或多个外部设备1004（例如键盘、指向设备等）通信，还可与一个或者多个使得用户能与计算装置1000交互的设备通信，和/或与使得该计算装置1000能与一个或多个其它计算装置进行通信的任何设备（例如路由器、调制解调器等等）通信。这种通信可以通过输入/输出（I/O）接口1005进行。并且，计算装置1000还可以通过网络适配器1006与一个或者多个网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特网）通信。如图10所示，网络适配器1006通过总线1003与用于计算装置1000的其它模块通信。应当理解，尽管图中未表示出，可以结合计算装置1000使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

本申请实施例还提供一种计算机程序产品，本申请中的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。上述计算机程序产品包括一个或多个计算机程序或指令。在计算机上加载和执行上述计算机程序或指令时，全部或部分地执行本申请上述的流程或功能。上述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备、核心网设备、OAM或者其它可编程装置。

计算机可读存储介质可以作为计算机程序产品的一种实现，即本申请实施例还提供一种计算机可读存储介质，其包括计算机程序，当上述计算机程序被处理器执行时实现如上述任意一种故障预警的方法。

上述计算机程序或指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，上述计算机程序或指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。上述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是集成一个或多个可用介质的服务器、数据中心等数据存储设备。上述可用介质可以是磁性介质，例如，软盘、硬盘、磁带；也可以是光介质，例如，数字视频光盘；还可以是半导体介质，例如，固态硬盘。该计算机可读存储介质可以是易失性或非易失性存储介质，或可包括易失性和非易失性两种类型的存储介质。

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

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

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

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

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

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

Claims (9)

1.一种故障预警的服务器，其特征在于，所述服务器包括处理器和存储器，其中，所述存储器存储有计算机程序，当所述计算机程序被所述处理器执行时，使得所述处理器执行如下步骤：

获取待检测设备的故障消息，并从所述故障消息中提取关键数据，所述关键数据用于描述所述故障消息的目标消息类型；所述待检测设备为充电桩；

确定与所述目标消息类型对应的目标配置项，所述配置项用于描述需监控的所述待检测设备的故障要素；

获取所述目标配置项的配置数据，并将所述关键数据以及配置数据合成待检测数据；其中所述获取所述目标配置项的配置数据，包括如下至少一个步骤：从所述故障消息中，提取所述目标配置项的第一配置数据，所述故障消息中包括故障的发生时间、故障编号以及故障描述；从预存储的所述待检测设备的设备信息中，查询所述目标配置项的第二配置数据，所述设备信息中包括待检测设备的位置信息以及标识；

获取与所述目标消息类型对应的目标校验规则，若所述待检测数据满足所述目标校验规则，则触发故障预警；

其中，所述获取所述目标配置项的配置数据，包括：基于预先设置的各个级别的消息类型与配置项的第一对应关系，确定与目标消息类型对应的目标配置项；

所述获取与所述目标消息类型对应的目标校验规则，包括：基于预先设置的各个级别的消息类型与校验规则的第二对应关系，获取与目标消息类型对应的目标校验规则。

2.如权利要求1所述的服务器，其特征在于，在每相邻两个级别中，下一级别的消息类型表示：对上一级别的消息类型进行划分得到的消息子类型；在每相邻两个级别中，下一级别的消息类型对应的配置项表示：对上一级别的消息类型对应的配置项集合进行划分得到的配置项子集合；

所述处理器具体用于：

按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的配置项集合中，确定与下一级消息类型对应的配置项子集合；

将所述目标消息类型包含的最后一级消息类型对应的配置项子集合中的配置项，作为所述故障消息对应的目标配置项。

3.如权利要求1所述的服务器，其特征在于，在每相邻两个级别中，下一级别的消息类型表示：对上一级别的消息类型进行划分得到的消息子类型；在每相邻两个级别中，下一级别的消息类型对应的校验规则表示：对上一级别的消息类型对应的检验规则集合进行划分得到的校验规则子集合；

所述处理器具体用于：

按照消息类型的级别由高到低的顺序，依次从上一级消息类型对应的校验规则集合中，确定与所述目标消息类型包含的下一级消息类型对应的校验规则子集合；

将所述目标消息类型包含的最后一级消息类型对应的校验规则子集合中的校验规则，作为与所述故障消息对应的目标校验规则。

4.如权利要求1所述的服务器，其特征在于，所述目标校验规则中包括多个配置项的参考取值；

若所述待检测数据中各配置项的实际取值与对应的参考取值一致，则确定所述待检测数据满足所述目标校验规则。

5.如权利要求1所述的服务器，其特征在于，所述确定与所述目标消息类型对应的目标校验规则之前，所述处理器还用于：

确定从所述待检测设备的历史上报消息中，查询到所述目标消息类型的消息，且查询到的消息的数量达到设定阈值。

6.如权利要求1～5任一所述的服务器，其特征在于，所述处理器触发故障预警时，执行如下至少一个步骤：

基于所述待检测数据生成用于记录所述待检测设备的故障情况的记录文件，并存储；

基于所述待检测数据生成告警通知，并向所述待检测设备的关联对象发送所述告警通知；

确定与所述故障类型对应的处理类型，并执行所述处理类型对应的处理操作。

7.如权利要求1～5任一所述的服务器，其特征在于，所述处理器具体用于：

依次从所述待检测设备的消息队列中，获取所述待检测设备的故障消息；其中，所述消息队列中存储有：根据时间顺序检测到的所述待检测设备的至少一个故障消息。

8.一种故障预警的方法，其特征在于，所述方法包括：

获取待检测设备的故障消息，并从所述故障消息中提取关键数据，所述关键数据用于描述所述故障消息的目标消息类型；所述待检测设备为充电桩；

确定与所述目标消息类型对应的目标配置项；所述配置项用于描述需监控的所述待检测设备的故障要素；

获取所述目标配置项的配置数据，并将所述关键数据以及配置数据合成待检测数据；其中所述获取所述目标配置项的配置数据，包括如下至少一个步骤：从所述故障消息中，提取所述目标配置项的第一配置数据，所述故障消息中包括故障的发生时间、故障编号以及故障描述；从预存储的所述待检测设备的设备信息中，查询所述目标配置项的第二配置数据，所述设备信息中包括待检测设备的位置信息以及标识；

获取与所述目标消息类型对应的目标校验规则，若所述待检测数据满足所述目标校验规则，则触发故障预警；

其中，所述获取所述目标配置项的配置数据，包括：基于预先设置的各个级别的消息类型与配置项的第一对应关系，确定与目标消息类型对应的目标配置项；

所述获取与所述目标消息类型对应的目标校验规则，包括：基于预先设置的各个级别的消息类型与校验规则的第二对应关系，获取与目标消息类型对应的目标校验规则。

9.一种计算机程序产品，包括计算机程序，其特征在于，当所述计算机程序被处理器执行时实现如权利要求8所述的方法。