与任何复杂的机械设备一样，由于日常使用的，CNC机器经历重复停机，需要各种形式的维护和人为干预，以保持它们运行。从常规部分变化和标准预防性维护，对内部计算机问题和机械故障等意外的并发症，每个机器将在运营的日期，月份和多年的过程中展示自己的停机事件自身性序列。这些通常在多个方面昂贵的事件，耗资宝贵的生产时间，有价值的操作时间，并且可能产生高维修/更换成本。每台机器的停机时间历史都成为了解整体机器健康和预测未来停机和性能的关键因素。
要想充分利用这些信息，就必须坚持不懈地做记录。传统上，后一项任务落在了操作员的肩上，他们的时间和注意力将更有效地用于运行和维护机器，而不是费力地记录和组织停机原因。然而，随着物联网的进步，密集而详细的机器行为现在可以通过多种数据流进行电子监控和记录。这为用自动化系统补充甚至取代人类对停机事件的记录提供了可能性。这可以采取为操作人员提供停机原因推荐系统的形式，甚至可以采用完全自主生成的停机注释层。
退出机器的数据非常丰富，但它的原始形式是我们所需要的可解释性水平的呐喊。理解机器告诉我们的内容，实际上学习他们正在发言的语言。
MachinineMetrics是一个独特的职位，可以完成这种雄心勃勃的任务。在过去的半十年中，我们已经从各种不同的机器模型中收集了数千家的数量数据，并且随着新机器商店采用我们的平台，数据收集继续迅速增长。
至关重要的是，我们从机器数据中自动获得的警报与运营商通过应用程序输入的停机事件注释相结合。因此，如果操作员在我们的数据库中标注停机事件为“由于破碎的工具而发生故障”，我们会意识到该事件、报警流以及导致该事件的机器行为。因此，我们可以尝试利用各种机器学习算法，将特定的机器数据模式与特定类型的停机注释关联起来。该过程生成的预测模型可用于未来停机事件的半自动化或全自动分类，以及每台机器历史的更一致、信息更丰富的记录。最终，这减轻了运营商的负担，并允许商店所有者获得更有效的停机原因的可见性。
我们的初始探索专注于由其制造商指定的电子报警码所代表的机器的“母语”。发现许多类的停机事件与某些前面的警报相关联，即使只是数据时间序列的粗略视觉检查。例如，这里是一台机器上大约两分钟的过程中发生的一系列警报，导致钻头钻头。
金色条纹表示每个警报打开时，黑色区域表示至少有一个警报仍处于激活状态。红色条纹表示机器停止的时间。
要制作更详细的后期后，让我们以表格形式查看此事件的引导
我们看到一系列警告，其次是一列漏故障，其次是机器下降20分钟。根据操作员的注释，这是由于“工具变更（计划改变）::钻\ n \ nbroke”。
进一步进入表格的内容，native_code列包含制造商级警报代码，以及文本列提供有关顶级警报类和（有时）子类的更多信息。不同机器对代码和文本进行了彻底不同的约定。
在这种情况下，没有提供有关警报的英语含义的信息，但这并不一定会造成问题。为了制定自动学习算法，它实际上更简单地直接将这些抽象代码与停机事件相关联。这为我们节省了例如手册的麻烦，即4305指示“Y轴不在转动位置，”并尝试准确地教授这意味着什么。它还减轻了我们的偏见和问题，因为我们可能会识别的特定警报而不必要地分散注意力。
期待操作员注释，问题的棘手部分原因是将停机的简单，明确含义与运营商输入的文本的字符串相关联。正如预期的那样，即使对于同一台机器问题，也是在我们平板电脑中输入的文本在各个客户，个人运营商和个别事件之间的变化很大。（注意看似任意的线条在“钻头\ n \ nbroke”中断。简而言之，不同的人以一种非常不同的方式进入注释，由于领域知识，技术的舒适性，以及使用MachinineMetrics系统的差异。
注意：表中的原始数据有两个空白的警报。什么是呢？仔细的外观揭示了它们与前面的警报的结束时间完全相关。它们有效地报警，其内容是“刚刚结束的警报” - 当时的机器语言等效。这是冗余的，因为已经记录了每个警报的结束时间。数据库中有大量空白警报，用于提供类似的目的，以及代表数据收集故障的非常小的分数。由于空白警报不是信息性的，因此我们随后将它们作为数据卫生的基本步骤。
在我们有希望使用机器提供的信息进行分类的任何希望如何对下行时间进行分类，我们更好地学习如何使用运营商提供的数据对它们进行分类。换句话说，从大可能的一千种不同细粒度的原因下降，人类可以用英语表达那些原因的不可数方式（迅速蹒跚而声称），可以我们阻止将下降时间转换为明确定义的类别？
执行此任务的一种方法是通过手动梳理所有停机注释并根据我们（希望）训练有素的人为判断和对英语语言的理解来将它们分配给类别。但是，我们的数据库目前包含近2000万元注释的停机事件，因此这需要一段时间。
自动化任务落入既定的自然语言处理领域（NLP）。我们正在构建这种类型的可靠模型，用于对注释文本进行分类。在短期内，我们已经确定了许多与少数广泛类别的无计划的停机事件紧密相关的关键字，这是通过研究在我们应用程序中分类的注释的随机归档来验证的。这些类别是分解那冷却剂， 和润滑剂。（第一个包括上面的钻突破例。）即使在这些有限的类中，也远远捕获所有注释，但是已知它确实捕获的那些是值得信赖的。
下一步是要查看哪些机器。不同的机器制作和适配器类型有效地用不同的警报语言发言，并且每个都需要单独学习。我们通过挑选制作/类型来启动，使我们提供最多的干净分类次数。这些是在我们的MTConnect适配器上运行的okumas，代表百种单独的机器以及约3,000个分配给上述三类的时间。
最后，就基本数据准备而言，我们需要确定每个停机时间对应的警报序列。许多组警报是单独发生的，远离任何其他警报或停机时间。例如，将中断的drill事件缩小到包括之前的12个小时，情况是这样的
我们以前看过的全部警报现在坐在红色条带下方，标志着停机事件的开始。显然，在该机器之前有很多警报活动突发。虽然这些可能会对钻头突破发生的时间巧妙地提供了几个小时后，我们将尽力保持简单的事情，并杂草出来。
我们如何以严谨的方式做到这一点？我们首先根据固定的时间间隙阈值将警报集聚到孤立的序列中。然后只连接每个注释只有最新的序列。在这种情况下，钻取中断事件仅被附加到我们之前看的警报（减去空白）。
为了确定分离序列的适当时间间隙，考虑相邻警报的间距的分布。（注意绘图上的对数时间刻度和1 ms的最小限定间隙以避免日志（0）。）
中值分离大约四秒钟，并且周围存在局部峰值。因此，我们推断出几秒钟或更短的是簇内警报的典型分离。但尾巴非常宽，而较长的时间差距有助于确保更少的警报簇被不必要地分开。虽然在情节中没有明显明显，但值得注意的是，第90百分位数有超过七分钟。我们为我们的时间间隙阈值修复十分钟作为一个漂亮的圆形号码。最终的表现结果不对这一选择非常敏感。
在这个阶段，我们可以收集一组约3,000个清洁的（注释，报警序列）。看看警报的native_codes（并忽略他们的文本和时间戳信息），我们将获得一个与这样的条目的大列表
你能发现任何模式吗？
思考每个单独的警报序列作为“文件”，我们现在面临与经典文本分类问题密切相关的问题，但词汇量由机器报警代码组成。（NLP，拿两个。）一个简单，常用的策略然后立即建议自己：将每个文件视为一袋单词，我们只关注字数而不是他们的订购。由于我们在这里处理警报而不是言语，我们可能会调用这样的策略是一袋警报。然后，这种高度减少的数据版本用作我们机器学习模型的输入。
这里可以为我们提供一种用于建筑和评估此类模型的优秀工具。例如，有一个标准的技巧，用于加权称为称为单词计数TF-IDF，我们发现略微增强歧视力。目前，我们采取TF-IDF加权袋的报警，并将它们送入多级逻辑回归模型。最终的结果是一个模型，当出现一个新的停机事件之前有一系列的警报时，将尝试对实际发生的类别进行知情猜测，并在停机弹出窗口中向操作人员提出建议。
现在，我们不指望这种模式是完美的，但我们至少希望它比随机猜测更好。实际上，希望它更接近完美而不是随机。但要评估，我们需要一种衡量模型性能的程序。
为此，我们雇用另一个标准技巧：交叉验证。数据随机分为十个块。我们在这些块中的九个中恢复了组合数据的模型，然后检查该模型的预测注释是否在剩余块中的真实注释。此过程重复十次，每次都持有不同的块进行测试。然后，（真正的注释，预测注释）的组合列表，然后给出了模型如何在真正新数据上执行的近似图像。
作为评估模型的一组指标，我们将在每个预测的注释类中分类的模型中的每个真实批注类中的事件中的一部分计算。例如，对于分解，有多少（正确）被归类为分解，以及有多少人(错误地)被归为其中之一冷却剂要么润滑剂。此列表一起定义了一个混乱矩阵。用于警报/ TF-IDF / Logistic回归方法的杂乱矩阵是
作为参考，这里的一个完美模型就是单位矩阵(对角线上是1，否则是0)。随机猜测将是一个均匀填充0.3333…的矩阵。显然，我们处在两者之间。而且似乎有些混淆通道几乎没有。(例如,分解和润滑剂很少彼此混淆。）对于天真，或多或少的箱子型号而言也不错！
这个结果非常令人鼓舞。这意味着那里是关于警报模式中编码的停机时间的信息，我们已经可以在第一次探索性练习时开始访问这些信息了。
到目前为止展示的分析真的只是几个步骤。我们目前抛出的警报（时间，持续时间，文本内容）有大量信息，难消表明我们还有许多其他数据流（温度，负载等），我们尚未进入。使用这种丰富的数据应用强大的复杂模型的选项几乎无限制。工作还继续APACE开发一个完整的模型，用于将运营商的英语注释映射到一致的类别中。然后，数据库中的所有其他机器都有许多其他唯一的警报语言和数据流。
我们的短期目标是使用数据直接从警报模式中自动建立最重要的注释类别，并分配这些类别人类可解释的标签。这些数据衍生的类别将通过施工表现出与报警模式的紧密相关性，允许更可靠的模型并进一步避免人类偏见。在生产中，这些模型应该足够准确地用推荐引擎建议运营商。收集数据后，运营商如何获取我们的建议，我们可以将这些作为进一步标记的信息，以改进我们的系统更准确。
保持调整以获得进一步的发展！
准备授权你的车间？
了解更多.svg)
评论