CN117155761A - 一种基于智能动环监控管理平台的告警方法及*** - Google Patents

Abstract

本申请公开了一种基于智能动环监控管理平台的告警方法及***，其中，基于智能动环监控管理平台的告警方法，包括如下步骤：告警中心接收用户端的动环监控请求，根据动环监控请求创建动环监控框架；告警中心根据动环监控框架与相应的智能动环监控端通信，对智能动环监控端进行监控条件设置，完成设置后，告警中心接收智能动环监控端按照监控条件发送的实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果；若分析结果为异常，生成预告信息并发送至用户端，若分析结果为故障，生成告警信息并发送。本申请能够保证获取的数据时效性，能够对获取的数据进行自动分析，对已经发生的故障进行告警，以及对即将发生的故障进行预测和告警。

Description

一种基于智能动环监控管理平台的告警方法及***

技术领域

本申请涉及动环监控技术领域，尤其涉及一种基于智能动环监控管理平台的告警方法及***。

背景技术

动环监控是指针对各类机房中的动力设备及环境变量进行集中监控，即：动力环境监控。

目前，通常采用巡检的方式对动环机房设备进行监控，即：利用人工对动环机房设备进行检查，并将检查数据记录于纸质表单后，再录入***，但该方式获得的巡检数据的时效性无法保障，且很难及时发现设备数据出现的问题，工作效率低，错误率高。

此外，现有的监控平台通常只能提供上传数据，或对已经发生故障的数据进行提醒。但监控平台获取的动环设备上传数据会随着时间推移发生变化，而移动终端上显示的还是旧的数据，会导致平台获取的上传数据与移动终端上显示的数据不一致，从而影响了对设备运行情况的判断，且现有的监控平台也无法对即将发生的故障进行预测和告警。

发明内容

本申请的目的在于提供一种基于智能动环监控管理平台的告警方法及***，能够保证获取的数据时效性，能够对获取的数据进行自动分析，对已经发生的故障进行告警，以及对即将发生的故障进行预测和告警。

为达到上述目的，本申请提供一种基于智能动环监控管理平台的告警方法，包括如下步骤：S1：告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架，其中，动环监控框架至少包括：常规监控子框架和定义监控子框架；S2：告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置，完成设置后，执行S3；S3：告警中心接收智能动环监控端按照监控条件发送的实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果；其中，分析结果为：正常、异常或故障，若分析结果为异常，则生成预告信息，并发送至用户端，若分析结果为故障，则生成告警信息，并发送至用户端。

如上的，其中，告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架的子步骤如下：对动环监控请求中的每个监控需求内容进行关键词提取，获得多个需求关键词包，一个需求关键词包中包括多个需求关键词，其中，动环监控请求至少包括：多个监控需求内容和用户端ID；根据预先设置的常规项关键词集合对每个需求关键词包进行判别分析，生成判别值，若判别值大于或等于判别阈值，则生成的判断结果为属于，并生成第一处理序号；若判别值小于判别阈值，则生成的判断结果为不属于，并生成第二处理序号；若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架；若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架；将常规监控子框架和定义监控子框架作为动环监控框架。

如上的，其中，若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架的子步骤如下：S131：创建常规监控表，其中，常规监控表至少包括：多个常规标题单元格，每个常规标题单元格均对应多个常规内容填写单元格；常规标题单元格至少包括：常规项序号、常规项名称、常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值、智能动环监控端信息和常规项监控条件；S132：将第一处理序号最小的监控需求内容作为当前监控需求内容，并将该第一处理序号作为当前监控需求内容的常规项序号，根据当前监控需求内容进行自动查询，获得查询内容，并将常规项序号和查询内容分别填写于相应的常规内容填写单元格内，完成填写后，执行S133；S133：对当前监控需求内容的常规项序号进行判断，若当前监控需求内容的常规项序号小于第一处理序号的总数，则剔除当前监控需求内容后，执行S132；若当前监控需求内容的常规项序号等于第一处理序号的总数，则剔除当前监控需求内容后，将完成填写后的常规监控表作为常规监控子框架。

如上的，其中，若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架的子步骤如下：S141：创建定义监控表，其中，定义监控表至少包括：多个定义标题单元格，每个定义标题单元格均对应多个定义内容填写单元格；定义标题单元格至少包括：定义项序号、定义项名称、定义项正常范围值、定义项异常范围值、定义项故障范围值、智能动环监控端信息和定义项监控条件；S142：将第二处理序号最小的监控需求内容作为当前监控需求内容，并将该第二处理序号作为当前监控需求内容的定义项序号，对当前监控需求内容进行自动识别，获得多个识别内容，并将定义项序号和多个识别内容分别填写于相应的定义内容填写单元格内，完成填写后，执行S143；S143：对当前监控需求内容的定义项序号进行判断，若当前监控需求内容的定义项序号小于第二处理序号的总数，则剔除当前监控需求内容后，执行S142；若当前监控需求内容的定义项序号等于第二处理序号的总数，则剔除当前监控需求内容后，将完成填写后的定义监控表作为定义监控子框架。

如上的，其中，告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置的子步骤如下：创建第一通信通道和第二通信通道；通过第一通信通道与常规监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据常规项监控条件对智能动环监控端进行监控条件设置；通过第二通信通道与定义监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据定义项监控条件对智能动环监控端进行监控条件设置。

如上的，其中，接收实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果的子步骤如下：接收实时数据包，并根据通信通道确定运行框架，若通信通道为第一通信通道，则确定常规监控子框架为运行框架，若通信通道为第二通信通道，则确定定义监控子框架为运行框架；根据运行框架对实时数据包进行分析，获得分析结果，其中，实时数据包至少包括：实时数据名称和实时数值。

如上的，其中，当运行框架为常规监控子框架时，根据运行框架对实时数据包进行分析，获得分析结果的子步骤如下：对实时数据包进行读取，确定实时数据包中的实时数据名称为当前常规项名称，按照常规项序列从小至大的顺序依次对常规标题单元格进行遍历，并确定常规项名称与当前常规项名称一致的常规标题单元格为比对数据；通过比对数据对实时数据包中的实时数值进行分析，确定实时数值所属的范围，若实时数值位于常规项正常范围值内，则生成的分析结果为正常；若实时数值位于常规项异常范围值内，则生成的分析结果为异常；若实时数值位于常规项故障范围值内，则生成的分析结果为故障。

如上的，其中，当运行框架为常规监控子框架时，若分析结果为异常，则生成预告信息的子步骤如下：向智能动环监控端发送增采指令，其中，增采指令至少包括：增采时间段和增采频次；接收执行增采指令获取的多个验证数据包，对验证数据包进行分析，获得预测故障时间和预测故障概率，并根据预告时间、异常时间、预测故障时间和预测故障概率生成预告信息，其中，验证数据包至少包括：增采序列、增采时间、验证数据名称和验证数值。

如上的，其中，当运行框架为常规监控子框架时，预测故障时间的表达式如下：

；

其中，为预测故障时间，/>为常规项异常范围值中的最小值；/>为本次智能动环监控端根据常规项监控条件采集的实时数据包中的实时数值；/>为增采序列为/>的验证数据包的验证数值；/>为增采序列为/>的验证数据包的验证数值；/>为相邻的验证数据包之间的增采时间间隔；/>，/>为增采序列的总个数。

本申请还提供一种基于智能动环监控管理平台的告警***，包括：至少一个用户端、多个智能动环监控端和告警中心；其中，用户端：用于发送动环监控请求，接收预告信息和/或告警信息；智能动环监控端：用于与告警中心通信，并允许告警中心进行监控条件设置；完成设置后，根据监控条件采集实时数据包，并发送；告警中心至少包括：告警分析单元和存储单元；其中，告警分析单元：用于执行上述的基于智能动环监控管理平台的告警方法；存储单元：用于存储监控框架库；存储常规项信息库，常规项信息库包括多种设备、机器和/或***的常规监控项信息，每个常规监控项信息至少包括：常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值和常规项监控条件。

本申请能够直接与智能动环监控端通信，实时获取数据，能够通过构建的动环监控框架自动对实时获取的数据进行分析，获得分析结果，并及时将根据分析结果生成预告信息或告警信息发送给用户端，从而实现对已经发生的故障进行告警，以及对即将发生的故障进行预测和告警。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为基于智能动环监控管理平台的告警***一种实施例的结构示意图；

图2为基于智能动环监控管理平台的告警方法一种实施例的流程图。

具体实施方式

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

如图1所示，本申请提供一种基于智能动环监控管理平台的告警***，包括：至少一个用户端1、多个智能动环监控端2和告警中心3。

其中，用户端1：用于发送动环监控请求，接收预告信息和/或告警信息。

智能动环监控端2：用于与告警中心3通信，并允许告警中心3进行监控条件设置；完成设置后，根据监控条件采集实时数据包，并发送。

告警中心3至少包括：告警分析单元31和存储单元32。

其中，告警分析单元31：用于执行下述的基于智能动环监控管理平台的告警方法。

存储单元32：用于存储监控框架库，监控框架库包括多个动环监控框架；存储常规项信息库，常规项信息库包括多种设备、机器和/或***的常规监控项信息，每个常规监控项信息至少包括：常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值和常规项监控条件。

如图2所示，本申请提供一种基于智能动环监控管理平台的告警方法，包括如下步骤：

S1：告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架，其中，动环监控框架至少包括：常规监控子框架和定义监控子框架。

进一步的，告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架的子步骤如下：

S11：对动环监控请求中的每个监控需求内容进行关键词提取，获得多个需求关键词包，一个需求关键词包中包括多个需求关键词，其中，动环监控请求至少包括：多个监控需求内容和用户端ID。

具体的，监控需求内容包括：监控数据项，以及每个监控数据项对应的监控需求。

其中，监控数据项为：需要进行监控的数据的名称。一种监控数据对应一个监控数据项。监控数据至少包括：各设备、机器和/或***的运行数据，以及运行环境数据。

监控需求为：对用户端需要进行监控的数据的要求的描述，该描述可以为文字、图表和/或符号。

需求关键词为：从监控需求中提取的用于准确并简要地表述监控数据的监控要求的关键词。

S12：根据预先设置的常规项关键词集合对每个需求关键词包进行判别分析，生成判别值，若判别值大于或等于判别阈值，则生成的判断结果为属于，并生成第一处理序号；若判别值小于判别阈值，则生成的判断结果为不属于，并生成第二处理序号。

进一步的，判别值的表达式如下：

；

其中，为常规项关键词集合与第/>个需求关键词包之间的判别值；/>为常规项关键词集合中的第/>个常规项关键词与第/>个需求关键词包的第/>个需求关键词的词义相关度；/>为与第/>个需求关键词包的需求关键词具有词义相关度的常规项关键词的总个数；/>，/>为第/>个需求关键词包中的需求关键词的总个数，，/>为常规项关键词集合中的常规项关键词的总个数。

具体的，词义相关度即为词义的相关和/或相似的值，通过预先训练好的判别模型即可获得两个关键词之间的相关和/或相似的值。

S13：若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架。

具体的，属于常规项的监控需求内容为需要进行监控的设备、机器和/或***（例如：动力***和运行设备等）的相关信息。

进一步的，若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架的子步骤如下：

S131：创建常规监控表，其中，常规监控表至少包括：多个常规标题单元格，每个常规标题单元格均对应多个常规内容填写单元格；常规标题单元格至少包括：常规项序号、常规项名称、常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值、智能动环监控端信息和常规项监控条件。

具体的，常规项序号：需要进行监控的数据的序号。一个监控需求内容对应一个常规项序号。同一个监控需求内容的常规项序号与其第一处理序号一致。

作为一个实施例，常规项序号按照处理监控需求内容的顺序自动生成或根据用户端的设定生成，本申请优选为同一个监控需求内容的常规项序号与其第一处理序号一致。

常规项名称：与需要进行监控的数据的名称一致。

常规项基础信息：需要进行监控的设备、机器和/或***的相关信息，至少包括：设备、机器和/或***的编号和设备、机器和/或***的型号。

常规项正常范围值：需要进行监控的数据处于正常范围的值，即：需要进行监控的设备、机器和/或***正常运行时的运行数据。

常规项异常范围值：需要进行监控的数据处于异常或临近故障范围值的值，即：需要进行监控的设备、机器和/或***处于异常运行或临近故障状态时的运行数据。

常规项故障范围值：需要进行监控的数据处于故障范围的值，即：需要进行监控的设备、机器和/或***处于故障状态的运行数据。

智能动环监控端信息：用于对需要进行监控的数据进行采集的智能动环监控端的相关信息；

常规项监控条件：智能动环监控端达到常规项监控条件时，获取需要进行监控的数据，并将该数据作为实时数据包发送至告警中心。

其中，常规项监控条件至少包括：常规间隔时间。

常规间隔时间为智能动环监控端下一次采集实时数据包和上一次采集实时数据包之间所需间隔的时间段，常规间隔时间可以为n秒钟、n分钟、n小时、n天、n周、n月、n季度或n年，常规间隔时间的具体值根据实际情况而定。

S132：将第一处理序号最小的监控需求内容作为当前监控需求内容，并将该第一处理序号作为当前监控需求内容的常规项序号，根据当前监控需求内容进行自动查询，获得查询内容，并将常规项序号和查询内容分别填写于相应的常规内容填写单元格内，完成填写后，执行S133。

具体的，一个监控需求内容对应一个常规项序号、一个常规项名称、一个常规项基础信息、一个常规项正常范围值、一个常规项异常范围值、一个常规项故障范围值、一个智能动环监控端信息和一个常规项监控条件。

进一步的，根据当前监控需求内容进行自动查询，获得查询内容的子步骤如下：

S1321：根据当前监控需求内容生成第一查询指令，其中，第一查询指令至少包括：查询位置和查询内容，其中，查询位置为常规项信息库，查询内容为：需要进行监控的设备、机器和/或***的相关信息。

S1322：根据查询指令对常规项信息库进行查询，若常规项信息库中具有与需要进行监控的设备、机器和/或***的相关信息一致的常规项基础信息，则将该常规项基础信息所属的常规监控项信息作为查询内容；若常规项信息库中不具有与需要进行监控的设备、机器和/或***的相关信息一致的常规项基础信息，则执行S1323。

S1323：生成第二查询指令，根据第二查询指令从网络中搜索查询内容或根据第二查询指令从用户端获取查询内容，并执行S1324，其中，第二查询指令至少包括：查询位置、查询内容和查询项，查询位置为：用户端ID或网络地址，查询内容为：需要进行监控的设备、机器和/或***的相关信息，查询项为：常规项正常范围值、常规项异常范围值、常规项故障范围值和常规项监控条件。

S1324：根据查询内容生成新的常规监控项信息，并将新的常规监控项信息存储于常规项信息库内。

S133：对当前监控需求内容的常规项序号进行判断，若当前监控需求内容的常规项序号小于第一处理序号的总数，则剔除当前监控需求内容后，执行S132；若当前监控需求内容的常规项序号等于第一处理序号的总数，则剔除当前监控需求内容后，将完成填写后的常规监控表作为常规监控子框架。

S14：若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架。

具体的，属于定义项的监控需求内容为需要进行监控的运行环境（例如：温度、湿度、门磁、烟雾、震动、红外、窗破和/或水浸等信息）的相关信息，属于定义项的监控需求内容至少包括：定义项名称、定义项正常范围值、定义项异常范围值、定义项故障范围值、智能动环监控端信息和定义项监控条件。

进一步的，若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架的子步骤如下：

S141：创建定义监控表，其中，定义监控表至少包括：多个定义标题单元格，每个定义标题单元格均对应多个定义内容填写单元格；定义标题单元格至少包括：定义项序号、定义项名称、定义项正常范围值、定义项异常范围值、定义项故障范围值、智能动环监控端信息和定义项监控条件。

具体的，定义项序号：需要进行监控的数据的序号。一个监控需求内容对应一个定义项序号。同一个监控需求内容的定义项序号与其第二处理序号一致。

作为一个实施例，定义项序号按照处理监控需求内容的顺序自动生成或根据用户端的设定生成，本申请优选为同一个监控需求内容的定义项序号与其第二处理序号一致。

定义项名称：与需要进行监控的数据的名称一致。

定义项正常范围值：需要进行监控的数据处于正常范围的值，即：需要进行监控的运行环境处于用户端设定的正常状态时的数值。

定义项异常范围值：需要进行监控的数据处于异常或临近故障范围值的值，即：需要进行监控的运行环境处于用户端设定的异常状态或临近故障状态时的数值。

定义项故障范围值：需要进行监控的数据处于故障范围的值，即：需要进行监控的运行环境处于用户端设定的故障状态时的数值。

智能动环监控端信息：用于对需要进行监控的数据进行采集的智能动环监控端的相关信息；

定义项监控条件：智能动环监控端达到定义项监控条件时，获取需要进行监控的数据，并将该数据作为实时数据包发送至告警中心。

其中，定义项监控条件至少包括：定义间隔时间。

定义间隔时间为智能动环监控端下一次采集实时数据包和上一次采集实时数据包之间所需间隔的时间段，定义间隔时间可以为m秒钟、m分钟、m小时、m天、m周、m月、m季度或m年，定义间隔时间的具体值根据实际情况而定。

S142：将第二处理序号最小的监控需求内容作为当前监控需求内容，并将该第二处理序号作为当前监控需求内容的定义项序号，对当前监控需求内容进行自动识别，获得多个识别内容，并将定义项序号和多个识别内容分别填写于相应的定义内容填写单元格内，完成填写后，执行S143。

具体的，一个监控需求内容对应一个定义项序号、一个定义项名称、一个定义项正常范围值、一个定义项异常范围值、一个定义项故障范围值、一个智能动环监控端信息和一个定义项监控条件。

S143：对当前监控需求内容的定义项序号进行判断，若当前监控需求内容的定义项序号小于第二处理序号的总数，则剔除当前监控需求内容后，执行S142；若当前监控需求内容的定义项序号等于第二处理序号的总数，则剔除当前监控需求内容后，将完成填写后的定义监控表作为定义监控子框架。

S15：将常规监控子框架和定义监控子框架作为动环监控框架。

S2：告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置，完成设置后，执行S3。

进一步的，告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置的子步骤如下：

S21：创建第一通信通道和第二通信通道。

S22：通过第一通信通道与常规监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据常规项监控条件对智能动环监控端进行监控条件设置。

S23：通过第二通信通道与定义监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据定义项监控条件对智能动环监控端进行监控条件设置。

S3：告警中心接收智能动环监控端按照监控条件发送的实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果；其中，分析结果为：正常、异常或故障，若分析结果为异常，则生成预告信息，并发送至用户端，其中，预告信息至少包括：预告时间、异常时间、预测故障时间和预测故障概率；若分析结果为故障，则生成告警信息，并发送至用户端，其中告警信息至少包括：故障数据名称、故障时间和故障数值。

具体的，若分析结果为正常，则无需向用户端发送信息，并继续执行S3。

进一步的，接收实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果的子步骤如下：

S31：接收实时数据包，并根据通信通道确定运行框架，若通信通道为第一通信通道，则确定常规监控子框架为运行框架，若通信通道为第二通信通道，则确定定义监控子框架为运行框架。

S32：根据运行框架对实时数据包进行分析，获得分析结果，其中，实时数据包至少包括：实时数据名称和实时数值。

进一步的，作为一个实施例，当运行框架为常规监控子框架时，根据运行框架对实时数据包进行分析，获得分析结果的子步骤如下：

T1：对实时数据包进行读取，确定实时数据包中的实时数据名称为当前常规项名称，按照常规项序列从小至大的顺序依次对常规标题单元格进行遍历，并确定常规项名称与当前常规项名称一致的常规标题单元格为比对数据。

T2：通过比对数据对实时数据包中的实时数值进行分析，确定实时数值所属的范围，若实时数值位于常规项正常范围值内，则生成的分析结果为正常；若实时数值位于常规项异常范围值内，则生成的分析结果为异常；若实时数值位于常规项故障范围值内，则生成的分析结果为故障。

进一步的，当运行框架为常规监控子框架时，若分析结果为异常，则生成预告信息的子步骤如下：

U1：向智能动环监控端发送增采指令，其中，增采指令至少包括：增采时间段和增采频次。

具体的，增采时间段为需要增加数据采集次数的时间段，增采时间段为：，其中，/>为增采时间段的开始节点，/>为增采时间段的结束节点，且增采时间段位于本次智能动环监控端根据常规项监控条件采集实时数据包的时间节点与下一次智能动环监控端根据常规项监控条件采集实时数据包的时间节点之间。增采时间段的开始节点和结束节点的具体时间根据实际情况设定。

增采频次为增采时间段内需要增加的采集次数，采集频次的具体值根据实际情况而定。

U2：接收执行增采指令获取的多个验证数据包，对验证数据包进行分析，获得预测故障时间和预测故障概率，并根据预告时间、异常时间、预测故障时间和预测故障概率生成预告信息，其中，验证数据包至少包括：增采序列、增采时间、验证数据名称和验证数值。

具体的，预告时间为向用户端发送预告信息的时间。

异常时间为本次智能动环监控端根据常规项监控条件采集实时数据包的时间节点。

预测故障时间为分析验证数据包后预测的会发生故障的时间节点与异常时间之间的变化时间段，即：以异常时间为起始时间节点，向未来推移一个预测故障时间后，即可得到预测的可能发生故障的具体的时间节点。

进一步的，当运行框架为常规监控子框架时，预测故障时间的表达式如下：

；

其中，为预测故障时间，/>为常规项异常范围值中的最小值；/>为本次智能动环监控端根据常规项监控条件采集的实时数据包中的实时数值；/>为增采序列为/>的验证数据包的验证数值；/>为增采序列为/>的验证数据包的验证数值；/>为相邻的验证数据包之间的增采时间间隔；/>，/>为增采序列的总个数。

具体的，增采序列的值根据采集验证数据包的时间由先往后的顺序依次增大。

进一步的，当运行框架为常规监控子框架时，预测故障概率的表达式如下：

；

其中，为预测故障概率；/>为时间变化参数；/>为数值变化参数；/>为预测故障时间的数值；/>为常规间隔时间的数值；/>为常规项异常范围值中的最小值的数值；/>为本次智能动环监控端根据常规项监控条件采集的实时数据包中的实时数值的数值。

具体的，在预测故障概率的表达式中，和/>为单位统一后的数值，和/>为单位统一后的数值，因此无需考虑数据的单位问题。/>和/>的具体值根据实际情况而定。

进一步的，作为另一个实施例，当运行框架为定义监控子框架时，根据运行框架对实时数据包进行分析，获得分析结果的子步骤如下：

F1：对实时数据包进行读取，确定实时数据包中的实时数据名称为当前定义项名称，按照定义项序列从小至大的顺序依次对定义标题单元格进行遍历，并确定定义项名称与当前定义项名称一致的定义标题单元格为比对数据。

F2：通过比对数据对实时数据包中的实时数值进行分析，确定实时数值所属的范围，若实时数值位于定义项正常范围值内，则生成的分析结果为正常；若实时数值位于定义项异常范围值内，则生成的分析结果为异常；若实时数值位于定义项故障范围值内，则生成的分析结果为故障。

进一步的，当运行框架为定义监控子框架时，若分析结果为异常，则生成预告信息的子步骤如下：

B1：向智能动环监控端发送插采指令，其中，插采指令至少包括：插采时间段和插采频次。

具体的，插采时间段为需要***数据采集次数的时间段，插采时间段为：，其中，/>为插采时间段的开始节点，/>为插采时间段的结束节点，且插采时间段位于本次智能动环监控端根据定义项监控条件采集实时数据包的时间节点与下一次智能动环监控端根据定义项监控条件采集实时数据包的时间节点之间。插采时间段的开始节点和结束节点的具体时间根据实际情况设定。

插采频次为插采时间段内需要增加的采集次数，采集频次的具体值根据实际情况而定。

B2：接收执行插采指令获取的多个插采数据包，对插采数据包进行分析，获得预测故障时间和预测故障概率，并根据预告时间、异常时间、预测故障时间和预测故障概率生成预告信息，其中，插采数据包至少包括：插采序列、插采时间、插采数据名称和插采数值。

具体的，预告时间为向用户端发送预告信息的时间。

异常时间为本次智能动环监控端根据定义项监控条件采集实时数据包的时间节点。

预测故障时间为分析插采数据包后预测的会发生故障的时间节点与异常时间之间的变化时间段，即：以异常时间为起始时间节点，向未来推移一个预测故障时间后，即可得到预测的可能发生故障的具体的时间节点。

进一步的，当运行框架为定义监控子框架时，预测故障时间的表达式如下：

；

其中，为预测故障时间，/>为定义项异常范围值中的最小值；为本次智能动环监控端根据定义项监控条件采集的实时数据包中的实时数值；为插采序列为/>的插采数据包的插采数值；/>为插采序列为/>的插采数据包的插采数值；/>为相邻的插采数据包之间的插采时间间隔；/>，/>为插采序列的总个数。

具体的，插采序列的值根据采集插采数据包的时间由先往后的顺序依次增大。

进一步的，当运行框架为定义监控子框架时，预测故障概率的表达式如下：

；

其中，为预测故障概率；/>为时间变化参数；/>为数值变化参数；为预测故障时间的数值；/>为定义间隔时间的数值；/>为定义项异常范围值中的最小值的数值；/>为本次智能动环监控端根据定义项监控条件采集的实时数据包中的实时数值的数值。

具体的，在预测故障概率的表达式中，和/>为单位统一后的数值，和/>为单位统一后的数值，因此无需考虑数据的单位问题。/>和/>的具体值根据实际情况而定。

本申请能够直接与智能动环监控端通信，实时获取数据，能够通过构建的动环监控框架自动对实时获取的数据进行分析，获得分析结果，并及时将根据分析结果生成预告信息或告警信息发送给用户端，从而实现对已经发生的故障进行告警，以及对即将发生的故障进行预测和告警。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，本申请的保护范围意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请保护范围及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种基于智能动环监控管理平台的告警方法，其特征在于，包括如下步骤：

S1：告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架，其中，动环监控框架至少包括：常规监控子框架和定义监控子框架；

S2：告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置，完成设置后，执行S3；

S3：告警中心接收智能动环监控端按照监控条件发送的实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果；其中，分析结果为：正常、异常或故障，若分析结果为异常，则生成预告信息，并发送至用户端，若分析结果为故障，则生成告警信息，并发送至用户端。

2.根据权利要求1所述的基于智能动环监控管理平台的告警方法，其特征在于，告警中心接收用户端的动环监控请求，并根据动环监控请求创建动环监控框架的子步骤如下：

对动环监控请求中的每个监控需求内容进行关键词提取，获得多个需求关键词包，一个需求关键词包中包括多个需求关键词，其中，动环监控请求至少包括：多个监控需求内容和用户端ID；

根据预先设置的常规项关键词集合对每个需求关键词包进行判别分析，生成判别值，若判别值大于或等于判别阈值，则生成的判断结果为属于，并生成第一处理序号；若判别值小于判别阈值，则生成的判断结果为不属于，并生成第二处理序号；

若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架；

若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架；

将常规监控子框架和定义监控子框架作为动环监控框架。

3.根据权利要求2所述的基于智能动环监控管理平台的告警方法，其特征在于，若判别结果为属于，则根据第一处理序号由小至大的顺序对监控需求内容进行处理，获得常规监控子框架的子步骤如下：

S131：创建常规监控表，其中，常规监控表至少包括：多个常规标题单元格，每个常规标题单元格均对应多个常规内容填写单元格；常规标题单元格至少包括：常规项序号、常规项名称、常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值、智能动环监控端信息和常规项监控条件；

S132：将第一处理序号最小的监控需求内容作为当前监控需求内容，并将该第一处理序号作为当前监控需求内容的常规项序号，根据当前监控需求内容进行自动查询，获得查询内容，并将常规项序号和查询内容分别填写于相应的常规内容填写单元格内，完成填写后，执行S133；

S133：对当前监控需求内容的常规项序号进行判断，若当前监控需求内容的常规项序号小于第一处理序号的总数，则剔除当前监控需求内容后，执行S132；若当前监控需求内容的常规项序号等于第一处理序号的总数，则剔除当前监控需求内容后，将完成填写后的常规监控表作为常规监控子框架。

4.根据权利要求3所述的基于智能动环监控管理平台的告警方法，其特征在于，若判别结果为不属于，则根据第二处理序号由小至大的顺序对监控需求内容进行处理，获得定义监控子框架的子步骤如下：

S141：创建定义监控表，其中，定义监控表至少包括：多个定义标题单元格，每个定义标题单元格均对应多个定义内容填写单元格；定义标题单元格至少包括：定义项序号、定义项名称、定义项正常范围值、定义项异常范围值、定义项故障范围值、智能动环监控端信息和定义项监控条件；

S142：将第二处理序号最小的监控需求内容作为当前监控需求内容，并将该第二处理序号作为当前监控需求内容的定义项序号，对当前监控需求内容进行自动识别，获得多个识别内容，并将定义项序号和多个识别内容分别填写于相应的定义内容填写单元格内，完成填写后，执行S143；

S143：对当前监控需求内容的定义项序号进行判断，若当前监控需求内容的定义项序号小于第二处理序号的总数，则剔除当前监控需求内容后，执行S142；若当前监控需求内容的定义项序号等于第二处理序号的总数，则剔除当前监控需求内容后，将完成填写后的定义监控表作为定义监控子框架。

5.根据权利要求4所述的基于智能动环监控管理平台的告警方法，其特征在于，告警中心根据动环监控框架与相应的智能动环监控端通信，并对智能动环监控端进行监控条件设置的子步骤如下：

创建第一通信通道和第二通信通道；

通过第一通信通道与常规监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据常规项监控条件对智能动环监控端进行监控条件设置；

通过第二通信通道与定义监控子框架中的智能动环监控端信息所对应的智能动环监控端通信，并根据定义项监控条件对智能动环监控端进行监控条件设置。

6.根据权利要求5所述的基于智能动环监控管理平台的告警方法，其特征在于，接收实时数据包，根据动环监控框架对实时数据包进行分析，获得分析结果的子步骤如下：

接收实时数据包，并根据通信通道确定运行框架，若通信通道为第一通信通道，则确定常规监控子框架为运行框架，若通信通道为第二通信通道，则确定定义监控子框架为运行框架；

根据运行框架对实时数据包进行分析，获得分析结果，其中，实时数据包至少包括：实时数据名称和实时数值。

7.根据权利要求6所述的基于智能动环监控管理平台的告警方法，其特征在于，当运行框架为常规监控子框架时，根据运行框架对实时数据包进行分析，获得分析结果的子步骤如下：

对实时数据包进行读取，确定实时数据包中的实时数据名称为当前常规项名称，按照常规项序列从小至大的顺序依次对常规标题单元格进行遍历，并确定常规项名称与当前常规项名称一致的常规标题单元格为比对数据；

通过比对数据对实时数据包中的实时数值进行分析，确定实时数值所属的范围，若实时数值位于常规项正常范围值内，则生成的分析结果为正常；若实时数值位于常规项异常范围值内，则生成的分析结果为异常；若实时数值位于常规项故障范围值内，则生成的分析结果为故障。

8.根据权利要求7所述的基于智能动环监控管理平台的告警方法，其特征在于，当运行框架为常规监控子框架时，若分析结果为异常，则生成预告信息的子步骤如下：

向智能动环监控端发送增采指令，其中，增采指令至少包括：增采时间段和增采频次；

接收执行增采指令获取的多个验证数据包，对验证数据包进行分析，获得预测故障时间和预测故障概率，并根据预告时间、异常时间、预测故障时间和预测故障概率生成预告信息，其中，验证数据包至少包括：增采序列、增采时间、验证数据名称和验证数值。

9.根据权利要求8所述的基于智能动环监控管理平台的告警方法，其特征在于，当运行框架为常规监控子框架时，预测故障时间的表达式如下：

；

其中，为预测故障时间，/>为常规项异常范围值中的最小值；/>为本次智能动环监控端根据常规项监控条件采集的实时数据包中的实时数值；/>为增采序列为/>的验证数据包的验证数值；/>为增采序列为/>的验证数据包的验证数值；/>为相邻的验证数据包之间的增采时间间隔；/>，/>为增采序列的总个数。

10.一种基于智能动环监控管理平台的告警***，其特征在于，包括：至少一个用户端、多个智能动环监控端和告警中心；

其中，用户端：用于发送动环监控请求，接收预告信息和/或告警信息；

智能动环监控端：用于与告警中心通信，并允许告警中心进行监控条件设置；完成设置后，根据监控条件采集实时数据包，并发送；

告警中心至少包括：告警分析单元和存储单元；

其中，告警分析单元：用于执行权利要求1- 9中任意一项所述的基于智能动环监控管理平台的告警方法；

存储单元：用于存储监控框架库，监控框架库包括多个动环监控框架；存储常规项信息库，常规项信息库包括多种设备、机器和/或***的常规监控项信息，每个常规监控项信息至少包括：常规项基础信息、常规项正常范围值、常规项异常范围值、常规项故障范围值和常规项监控条件。