CN110046146A - 基于移动边缘计算的工业设备的监测方法和装置 - Google Patents

Abstract

本公开提供了一种基于移动边缘计算的工业设备的监测方法，该方法包括：获取工业设备的数据，根据预设的故障识别模型判断数据是否为异常数据，当数据为异常数据时，则基于预设的故障原因识别模型确定异常数据的异常原因。本公开还提供了一种基于移动边缘计算的工业设备的监测装置。

Description

基于移动边缘计算的工业设备的监测方法和装置

技术领域

本公开实施例涉及互联网技术领域，特别涉及基于移动边缘计算的工业设备的监测方法和装置。

背景技术

随着互联网技术的深入发展和不断普及，互联网被广泛的应用于各个领域和各个行业。

在现有技术中，也有将工业设备与互联网技术相结合，进而实现对工业设备的监测。但是，主要的方式包括两种，一种是通过设置具有摄像功能的设备，通过具有摄像功能的设备对工业设备生产过程中的相关信息进行采集，再通过人工的方式对采集到的相关信息进行分析。另一种是通过传感器等方式对工业设备生产过程中的相关信息进行采集，并将相关信息进行打包，发送至工业设备对应的核心网，通过核心网对相关信息进行分析(也需要通过人工结合)。

发明内容

本公开实施例提供一种基于移动边缘计算的工业设备的监测方法和装置。

第一方面，本公开实施例提供了一种基于移动边缘计算的工业设备的监测方法，包括：

获取工业设备的数据；

根据预设的故障识别模型判断所述数据是否为异常数据；

当所述数据为异常数据时，则基于预设的故障原因识别模型确定所述异常数据的异常原因。

在一些实施例中，在所述根据预设的故障识别模型判断所述数据是否为异常数据之前，还包括：

获取所述工业设备的历史数据；

对所述历史数据进行分类，得到历史正常数据和历史异常数据；

基于所述历史正常数据确定所述故障识别模型；

基于所述历史异常数据确定所述故障原因识别模型。

在一些实施例中，所述基于所述历史正常数据确定所述故障识别模型，包括：

对所述历史正常数据进行归一化处理；

对归一化处理后的正常数据进行训练，得到所述故障识别模型。

在一些实施例中，所述基于所述历史异常数据确定所述故障原因识别模型，包括：

对所述历史异常数据进行归一化处理；

对归一化处理后的历史异常数据进行哑变量处理；

对哑变量处理后的历史异常数据进行训练，得到所述故障原因识别模型。

在一些实施例中，所述基于预设的故障原因识别模型确定所述异常数据的异常原因之后，还包括：

将所述异常数据的异常原因发送至终端；

接收用户通过所述终端发送的反馈信息；

响应于所述反馈信息中携带所述异常原因与预设的异常原因不相同的信息，基于所述反馈信息对所述故障原因识别模型进行更新。

第二方面，本公开实施例提供了一种基于移动边缘计算的工业设备的监测装置，包括：

获取模块，用于获取工业设备的数据；

判断模块，用于根据预设的故障识别模型判断所述数据是否为异常数据；

确定模块，用于当所述数据为异常数据时，则基于预设的故障原因识别模型确定所述异常数据的异常原因。

在一些实施例中，还包括：

所述获取模块还用于，获取所述工业设备的历史数据；

分类模块，用于对所述历史数据进行分类，得到历史正常数据和历史异常数据；

所述确定模块还用于，基于所述历史正常数据确定所述故障识别模型；

所述确定模块还用于，基于所述历史异常数据确定所述故障原因识别模型。

在一些实施例中，所述确定模块具体用于：

对所述历史正常数据进行归一化处理；

对归一化处理后的正常数据进行训练，得到所述故障识别模型。

在一些实施例中，所述确定模块具体用于：

对所述历史异常数据进行归一化处理；

对归一化处理后的历史异常数据进行哑变量处理；

对哑变量处理后的历史异常数据进行训练，得到所述故障原因识别模型。

在一些实施例中，还包括：

发送模块，用于将所述异常数据的异常原因发送至终端；

接收模块，用于接收用户通过所述终端发送的反馈信息；

更新模块，用于响应于所述反馈信息中携带所述异常原因与预设的异常原因不相同的信息，基于所述反馈信息对所述故障原因识别模型进行更新。

本公开实施例提供的获取工业设备的数据，根据预设的故障识别模型判断数据是否为异常数据，当数据为异常数据时，则基于预设的故障原因识别模型确定异常数据的异常原因，避免了现有技术中通过人工的方式进行分析造成的成本高，效率低等弊端，实现了高效且精准的监测的技术效果。

附图说明

附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为根据本公开实施例的基于移动边缘计算的工业设备的监测方法的示意图；

图2为根据本公开另一实施例的基于移动边缘计算的工业设备的监测方法的示意图；

图3为根据本公开实施例的确定故障识别模型的方法的示意图；

图4为根据本公开实施例的确定故障原因识别模型的方法的示意图；

图5为根据本公开另一实施例的基于移动边缘计算的工业设备的监测方法的示意图；

图6为根据本公开实施例的基于移动边缘计算的工业设备的监测装置的示意图；

图7为根据本公开另一实施例的基于移动边缘计算的工业设备的监测装置的示意图；

图8为根据本公开另一实施例的基于移动边缘计算的工业设备的监测装置的示意图；

图9为根据本公开实施例的应用场景框架示意图；

附图标记：1、获取模块，2、判断模块，3、确定模块，4、分类模块，5、发送模块，6、接收模块，7、更新模块，11、工业设备，12、网络，13、本地服务器，14、边缘云，15、服务网关。

具体实施方式

为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图对本发明提供的基于移动边缘计算的工业设备的监测方法和装置进行详细描述。

在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现且不应当被解释为限于本文阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或其群组。

本文所述实施例可借助本公开的理想示意图而参考平面图和/或截面图进行描述。因此，可根据制造技术和/或容限来修改示例图示。因此，实施例不限于附图中所示的实施例，而是包括基于制造工艺而形成的配置的修改。因此，附图中例示的区具有示意性属性，并且图中所示区的形状例示了元件的区的具体形状，但并不旨在是限制性的。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

根据本公开实施例的一个方面，本公开实施例提供了基于移动边缘计算的工业设备的监测方法。

请参阅图1，图1为根据本公开实施例的基于移动边缘计算的工业设备的监测方法的示意图。

如图1所示，该方法包括：

S1：获取工业设备的数据。

其中，工业设备指的是工业生产设备和各类机床，比如车床、铣床、磨床、刨床等机器。

数据包括工业设备的生产线名称、工业设备每秒生产的零件个数、工业设备的温度、工业设备所在车间(或厂房)的温度、工业设备所在车间(或厂房)的空气湿度、工业设备所在车间(或厂房)的电力消耗情况、工业设备所在车间(或厂房)的网络布线的网速等。

也就是说，数据大体可分为两大类，一类为生产数据(如工业设备每秒生产的零件个数)，另一类可分为环境数据(工业设备所在车间(或厂房)的电力消耗情况)。

可以理解的是，生产数据和环境数据是存在一定的关联关系的。即，不同的环境数据会造成生产数据的变化。同理，不同的生产数据也会造成环境数据的变化。

如：当生产数据为工业设备每秒生产的零件个数，且工业设备每秒生产的零件个数为a，而工业设备正常运作时，工业设备每秒生产的零件个数为b，a远远大于b。则会使得工业设备所在车间(或厂房)的电力消耗明显增大。

随着互联网技术的发展，逐渐实现了工业互联网。工业互联网开辟了新的领域以加快提高效率，减少低效和浪费，加强人的工作经验。

其中，移动边缘计算(英文全称为Mobile Edge Computing，简称MEC)可利用无线接入网络就近提供电信用户IT所需服务和云端计算功能，而创造出一个具备高性能、低延迟与高带宽的电信级服务环境，加速网络中各项内容、服务及应用的快速下载，让消费者享有不间断的高质量网络体验。

在本实施例中，基于移动边缘计算对工业设备进行监测，可实现节约时间，提高效率等技术效果。

S2：根据预设的故障识别模型判断数据是否为异常数据。

其中，异常数据是与正常数据相对的概念。正常数据是指工业设备正常运作时的数据，或者工业设备所需要的环境的数据(包括温度和湿度等)。而异常数据是指工业设备非正常运作时的数据，或者环境的数据并不能满足工业设备的需求，则该环境的数据即为异常数据。

在现有技术中，为提高工业设备的生产效率，以及加强对工业设备的管理，需要对工业设备进行监测，包括生产过程中的监测，也包括工业设备在停止运行进行检修时的监测。且主要采用的监测方法包括两种，一种是人工监测；另一种为通过借助辅助设备进行监测。如，具有摄像功能的设备。

然而，尽管通过辅助设备进行监测相对于人工监测的方式，会带来节约成本，提高效率的效果。但是，即便是通过辅助设备进行监测，也依然需要通过人工的方式进行分析，进行判断。

而在本实施例中，通过预先建立故障识别模型，通过故障识别模型对数据进行判断，以便确定该数据为正常数据还是异常数据。

具体地，将数据输入至故障识别模型，则故障识别模型进行一系列计算，会输出判断结果。

如，可采用现有技术中的神经网络模型，对输入的数据进行判断，判断该数据是正常数据，还是异常数据。

结合图2可知，在一些实施例中，在S2之前，该方法还包括：

S01：获取工业设备的历史数据。

其中，历史数据是指在当前时刻之前获取到的工业设备的数据。

S02：对历史数据进行分类，得到历史正常数据和历史异常数据。

基于上述描述可知，历史数据也包括历史生产数据和历史环境数据。而不管是历史生产数据还是历史环境数据，均可能存在异常数据。即，历史正常数据和历史异常数据。

如：若工业设备生产得到零件的参数与预设的要求的参数并不相同(此处的不相同是指即便考虑了误差也不相同)，则说明该零件的参数为异常数据。同理，若预设的工业设备的生产环境的温度与实际温度并不相同(此处的不相同是指即便考虑了误差也不相同)，则说明该温度为异常数据。

也就是说，基于将获取到的实际数据(即历史数据)与预设数据进行比较，可确定历史正常数据和历史异常数据。

在一些实施例中，在对历史数据进行分类时，设置两个不同的标识字段(标识字段是唯一标识实体实例的字段或字段组)。

如：设置标识字段为1和0。1为历史异常数据对应的标识字段，0为正常数据对应的标识字段。则当某历史数据为正常数据时，则在该正常数据的基础上增加标识字段1。

S03：基于历史正常数据确定故障识别模型。

结合图3可知，在一些实施例中，S03包括：

S03-1：对历史正常数据进行归一化处理。

其中，归一化处理是一种简化计算的方式，即将有量纲的表达式，经过变换，化为无量纲的表达式，成为标量。

具体地，针对所有的历史正常数据，如每秒生产的零件个数工业设备的温度、工业设备所在车间(或厂房)的温度、工业设备所在车间(或厂房)的空气湿度、工业设备所在车间(或厂房)的的电力消耗情况、工业设备所在车间(或厂房)的网络布线的网速等进行归一化处理。

优选地，归一化处理通过式1实现，式1：

X’＝(X-Xmin)/(Xmax–Xmin)。

其中，X为某历史正常数据，X’是该历史正常数据归一化处理后的数据，Xmin为该历史正常数据对应的最小值，Xmax为该历史正常数据对应的最大值。

S03-2：对归一化处理后的正常数据进行训练，得到故障识别模型。

通过归一化处理后正常数据，可实现减小历史异常数据的噪音；优化的过程，计算时间会快；且可实现统一量纲。

在一些实施例中，S03-2具体包括：以预设的循环神经网络模型(英文名称为LSTM)为基础模型，对归一化处理后的正常数据进行训练。将训练后的结果与预设的结果进行比较，若两个结果的相似度大于预设阈值，则将训练得到的模型确定为故障识别模型。

若两个结果的相似度小于或等于预设阈值，则对循环神经网络模型的参数(如学习率等)进行调整，将归一化处理后的数据再次进行训练，直至得到满足阈值要求对应的模型，进而确定该模型为故障识别模型。

S04：基于历史异常数据确定故障原因识别模型。

结合图4可知，在一些实施例中，S04包括：

S04-1：对历史异常数据进行归一化处理。

具体可参见上述对正常数据进行归一化处理的步骤，此处不再赘述。

S04-2：对归一化处理后的历史异常数据进行哑变量处理。

其中，哑变量即为虚拟变量(英文名称为Dummy Variables)，又称虚设变量或名义变量，用以反映质的属性的一个人工变量，是量化了的自变量。通常取值为0或1。

在步骤中，若所有的历史异常数据对应的故障原因有三种，分别为故障原因A、故障原因B和故障原因C。那么，在经过哑变量处理后。故障原因A对应的值为100，故障原因B对应的值为010，故障原因C对应的值为001。

S04-3：对哑变量处理后的历史异常数据进行训练，得到故障原因识别模型。

在该步骤中，将故障原因作为模型训练的目标值，将历史异常数据作为输入属性数据。构建多元分类模型，使用bagging算法实现。其中，bagging是一种用来提高学习算法准确度的方法，这种方法通过构造一个预测函数系列，然后以一定的方式将它们组合成一个预测函数。Bagging要求"不稳定"(不稳定是指数据集的小的变动能够使得分类结果的显著的变动)的分类方法。比如:决策树，神经网络算法。

当数据为异常数据时，则执行S3：基于预设的故障原因识别模型确定异常数据的异常原因。

在一些实施例中，可通过定期或不定期的方式对故障识别模型和/或故障原因识别模型进行更新。当然，为了确保监测的可靠性，同时对故障识别模型和故障原因识别模型进行更新。如：

定期更新：每一个月进行一次故障识别模型和故障原因识别模型的重新训练，避免故障识别模型和故障原因识别模型由于时效问题导致的预测不准确。

不定期更新：随机选取时间进行更新。或者，当对工业设备的供电情况、季节变化和温度变化等原因，对故障识别模型和故障原因识别模型进行重新训练。因为外界条件的变化直观反映在数据指标上，会影响训练的每个输入指标的权重，可能会导致故障识别模型和故障原因识别模型预测的不准确。

结合图5可知，在一些实施例中，在S3之后，该方法还包括：

S4：将异常数据的异常原因发送至终端。

其中，终端可以是移动设备例如手机、笔记本电脑平板电脑、个人数字助理等，也可以是固定设备，例如台式电脑等。

S5：接收用户通过终端发送的反馈信息。

用户(如工作人员)通过终端知晓异常数据的异常原因后，会再次对异常原因进行确认。并当确认异常原因为错误信息时，会反馈与异常数据对对应的正确的故障原因的反馈信息。

响应于反馈信息中携带异常原因与预设的异常原因不相同的信息，执行S6：基于反馈信息对故障原因识别模型进行更新。

若接收到用户通过终端发送的反馈信息，且该反馈信息中携带常原因与预设的异常原因不相同的信息。则说明故障原因识别模型存在误差，则基于该反馈信息对故障原因识别模型进行更新。进而确保故障原因识别模型的可靠性。

根据本公开实施例的另一个方面，本公开实施例还提供了一种基于移动边缘计算的工业设备的监测装置。

请参阅图6，图6为根据本公开实施例的基于移动边缘计算的工业设备的监测装置的示意图。

如图6所示，该装置包括：

获取模块1，用于获取工业设备的数据；

判断模块2，用于根据预设的故障识别模型判断数据是否为异常数据；

确定模块3，用于当数据为异常数据时，则基于预设的故障原因识别模型确定异常数据的异常原因。

结合图7可知，在一些实施例中，该装置还包括：

获取模块1还用于，获取工业设备的历史数据；

分类模块4，用于对历史数据进行分类，得到历史正常数据和历史异常数据；

确定模块3还用于，基于历史正常数据确定故障识别模型；

确定模块3还用于，基于历史异常数据确定故障原因识别模型。

在一些实施例中，确定模块3具体用于：

对历史正常数据进行归一化处理；

对归一化处理后的正常数据进行训练，得到故障识别模型。

在一些实施例中，确定模块4具体用于：

对历史异常数据进行归一化处理；

对归一化处理后的历史异常数据进行哑变量处理；

对哑变量处理后的历史异常数据进行训练，得到故障原因识别模型。

结合图8可知，在一些实施例中，该装置还包括：

发送模块5，用于将异常数据的异常原因发送至终端；

接收模块6，用于接收用户通过终端发送的反馈信息；

更新模块7，用于响应于反馈信息中携带异常原因与预设的异常原因不相同的信息，基于反馈信息对故障原因识别模型进行更新。

其中，将基于移动边缘计算的工业设备的监测装置部署与边缘云中，边缘云与工业设备之间通过有线网(或者无线网，或者蜂窝网络等)连接。

为使更加透彻的对本实施例的方案以及，本实施例的方案与现有技术的区别，现结合图1至图9对本实施例的方案进行详细的阐述。

其中，图9为根据本公开实施例的应用场景框架示意图。

在现有技术中，工业设备11通过网络12(如有线网、无线网等)与本地服务器13连接，以便通过网络12将工业设备11对应的数据发送至本地服务器13，由本地服务器对数据进行分析。而具体的分析方式主要由人工相结合。

而在本实施例中，工业设备11通过网络12与边缘云14连接。工业设备11通过网络12将采集到的历史数据发送至边缘云14。

其中，边缘云14中设置了数据处理模块，数据处理模块具体用于对接收到的历史数据进行汇总处理和/或格式处理(当然，也可包括其它处理)。

在一些实施例中，边缘云14可直接基于历史数据(以下所称历史数据均指经过数据处理模块处理后的历史数据)构建故障识别模型和故障原因识别模型(即上述确定故障识别模型的方案和故障原因识别模型的方案)。

优选地，为了加快数据处理效率，提高数据处理的准确性。边缘云14对接收到的历史数据进行处理后，将处理后的历史数据通过服务网关15发送至本地服务器13。

本地服务器13根据历史数据构建故障识别模型和故障原因识别模型(即上述确定故障识别模型的方案和故障原因识别模型的方案)。并将构建完成的故障识别模型和故障原因识别模型经过服务网关15发送至边缘云14。

边缘云14对故障识别模型和故障原因识别模型进行存储。并基于故障识别模型和故障原因识别模型实现对工业设备11的监测。具体基于故障识别模型和故障原因识别模型实现对工业设备11通过网络12传输的数据的监测。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (10)

1.一种基于移动边缘计算的工业设备的监测方法，包括：

获取工业设备的数据；

根据预设的故障识别模型判断所述数据是否为异常数据；

当所述数据为异常数据时，则基于预设的故障原因识别模型确定所述异常数据的异常原因。

2.根据权利要求1所述的方法，其中，在所述根据预设的故障识别模型判断所述数据是否为异常数据之前，还包括：

获取所述工业设备的历史数据；

对所述历史数据进行分类，得到历史正常数据和历史异常数据；

基于所述历史正常数据确定所述故障识别模型；

基于所述历史异常数据确定所述故障原因识别模型。

3.根据权利要求2所述的方法，其中，所述基于所述历史正常数据确定所述故障识别模型，包括：

对所述历史正常数据进行归一化处理；

对归一化处理后的正常数据进行训练，得到所述故障识别模型。

4.根据权利要求2所述的方法，其中，所述基于所述历史异常数据确定所述故障原因识别模型，包括：

对所述历史异常数据进行归一化处理；

对归一化处理后的历史异常数据进行哑变量处理；

对哑变量处理后的历史异常数据进行训练，得到所述故障原因识别模型。

5.根据权利要求1至4中任一项所述的方法，其中，所述基于预设的故障原因识别模型确定所述异常数据的异常原因之后，还包括：

将所述异常数据的异常原因发送至终端；

接收用户通过所述终端发送的反馈信息；

响应于所述反馈信息中携带所述异常原因与预设的异常原因不相同的信息，基于所述反馈信息对所述故障原因识别模型进行更新。

6.一种基于移动边缘计算的工业设备的监测装置，包括：

获取模块，用于获取工业设备的数据；

判断模块，用于根据预设的故障识别模型判断所述数据是否为异常数据；

确定模块，用于当所述数据为异常数据时，则基于预设的故障原因识别模型确定所述异常数据的异常原因。

7.根据权利要求6所述的方法，其中，还包括：

所述获取模块还用于，获取所述工业设备的历史数据；

分类模块，用于对所述历史数据进行分类，得到历史正常数据和历史异常数据；

所述确定模块还用于，基于所述历史正常数据确定所述故障识别模型；

所述确定模块还用于，基于所述历史异常数据确定所述故障原因识别模型。

8.根据权利要求7所述的方法，其中，所述确定模块具体用于：

对所述历史正常数据进行归一化处理；

对归一化处理后的正常数据进行训练，得到所述故障识别模型。

9.根据权利要求7所述的方法，其中，所述确定模块具体用于：

对所述历史异常数据进行归一化处理；

对归一化处理后的历史异常数据进行哑变量处理；

对哑变量处理后的历史异常数据进行训练，得到所述故障原因识别模型。

10.根据权利要求6至9中任一项所述的方法，其中，还包括：

发送模块，用于将所述异常数据的异常原因发送至终端；

接收模块，用于接收用户通过所述终端发送的反馈信息；

更新模块，用于响应于所述反馈信息中携带所述异常原因与预设的异常原因不相同的信息，基于所述反馈信息对所述故障原因识别模型进行更新。