夜雨聆风
过去重复性工作：机械诊断工程师的一天充满了大量的差旅，包括航班、高铁、出租车和租车通勤。他们往往花费大量的时间往返于项目现场，然后用某种便携式仪器收集设备数据，而不是真正分析数据和诊断问题。
后来，随着在线状态监测系统以及远程连接更加普及，出行减少了，但基本的数据简化、分析和诊断任务仍然保持不变。对于公司内部的机械工程师或振动分析师来说，这项工作可能变得很少或根本不需要出差，但基本的数据简化、分析和诊断任务与现场诊断工程师的任务基本相同。
如今，随着越来越多的人居家、远程办公，越来越多的公司精简员工队伍，少量人员需要承担更多的维护工作，以设备运维支持为例，可能只有一名工程师负责整个工厂的机械设备维护，如果工厂规模较小且地理位置分散，那么在工厂可能没有常驻的专业工程师，一名工程师（或一个团队）可能需要支持多个工厂。无论何种情况，故障诊断软件都能实现以更少的资源做更多的事情，大大提高效率。
嵌入知识，自动化重复性任务
借助在线状态监测系统可以实现数据的自动化采集，适当配置数据项以及采集频率，几乎不需要手动采集数据，但仍然需要照常开展数据处理、分析和诊断等工作。
重复从事这些数据分析工作后，是否存在一种系统化的方法，自动形成特定类型的图表，从而可以快速确定或排除某些故障。比如机器出现某种高频振动时，最可能的原因是转子不平衡或不对中。需要的图表类型和属性，根据过往的故障分析和诊断知识及工作经验可进行预设。某些故障很容易在时序图、波形轨道图中观察到，而另一些则在频谱图中较为明显。还有一些故障可能在时序图中有相似的波形，但在波特图中有明显的特征信号。关键在于，在使用振动和机器信息诊断时：采用系统化的方法。
日常工作中遵循的诊断“系统”或“决策树”可以被编码成一系列诊断规则，这些规则可以反复应用于状态监测系统收集的数据，而且，这些规则可复杂可简单。关键在于，用户能够理解、应用并定制这些规则，可以反映其独特的工艺条件和设备特性。
第一性原理与数据科学
当前LLM的发展如日中天，数据驱动的方法非常流行。一家大型软件供应商的用户群中进行的一项非正式调查显示，市场上有16家供应商声称自己都是一流顶尖的模型，但极少数能够真正解释清楚他们的系统或方法与其他供应商的区别与独特性，其中一家声称其获得了最大规模风投融资作为一个卖点。显而易见的是，最成功的系统是那些发现了细分应用领域并精通该领域的系统——而不仅仅掌握了通用的数据和数据驱动方法。虽然这类系统有其用武之地，但如果没有庞大的专职团队进行支撑，它们通常成本高昂且难以实施。因此通常出现在拥有数千名员工的大型组织中，比如GE、Siemens、MHI等，这些组织能组建专业团队来实施和维护，在中国的OEM、大学、专业公司，宣传起来高大上，实际项目却不如人意，往往是一锤子买卖，缺乏长期运营思维，一旦实施犹如泥潭越陷越深。大公司的专职团队不仅需要维护和“调优”此类系统，还需要输入大量包含已知“好”和“坏”行为数据来“训练”系统，使系统能够开始识别模式和异常情况。这类系统往往能告诉你出了问题，但未必能指出具体问题所在，它们更像是一种警报机制，仍然需要分析师深入挖掘数据，才能找到确切的问题和根本原因。
设备运维员在使用“第一原理”或“基于物理”的专家系统时，反而能取得很好的效果，比如TSI、TDM、Argus等等，他们已经非常了解特定类型图表中能寻找什么信息，而且采用的诊断方法既可重复又系统化。他们需要的仅仅是一种方法来嵌入并自动化这些方法，采用基于规则的方法能够轻松生成和修改自己的诊断规则。
随着LLM的发展，未来很重要的就是如何利用 AI Agent 对设备诊断分析工作进行流程编排。最好是不需要改变一个故障分析师的工作流，通过埋点获取各类分析过程和数据，从而逐步实现自动化。日常诊断分析中，需要用到哪些数据项、数据属性、图表类型，针对哪些工况进行分析，以及如何放大 / 缩小分析窗口等操作，均可由 Agent 自动执行。每个分析节点都会输出明确结论，全过程由系统自主完成，并支持语音交互，自动生成分析纪要。AI 可基于这套标准化流程，替代人工完成重复性诊断工作。
Skills（原子化技能）：充当“执行的双手”大模型本身无法直接操作图表。我们需要将日常诊断中的每一个微小动作封装成标准化的 API（即 Skill）。
引入示教编程（Teach by Demonstration）的理念，让用户自定义匹配现场特有的逻辑。
1.动作流录制（Action Logging）
当现场专家在可视化平台上进行一次深度诊断排查时，前端系统会在暗中记录所有的交互事件（数据埋点、录音等）。例如：专家选定了 Bearing_1_Vib 测点 -> 框选了转速突变前后的 10 秒窗口 -> 切换为波特图（Bode Plot） -> 提取了 1X 倍频的峰值。这些操作被录制为一个标准化的 JSON 序列。
- AI 解析：“专家正在进行过临界转速的振动分析。提取的变量是‘时间窗’和‘测点名称’。”
- 模板生成：LLM 自动将这段特定操作泛化为一个新的自定义组合技能（Skill Chain）或有向无环图（DAG），并将其命名为“过临界转速振动诊断流”。
当日常诊断工作交由 Agent 自动执行时，运转流程如下：
- 意图解析与触发：用户通过语音下发指令（例如：“执行一次月度燃烧室健康度扫描”）。Agent 解析意图，从库中调出对应的 DAG 执行流。
- 分步执行与节点判定：Agent 像脚本一样依次调用各个分析组件。每完成一个节点的分析（如图表渲染、趋势拟合），都会将图表数据特征（如斜率、波动率）送入小规模的判别模型中进行评估。
- 输出明确结论：节点会返回“有效（处于正常基线内）”或“无效（触发劣化阈值）”。如果是无效，Agent 会根据控制流决定是报警、继续深挖还是调用备用诊断链。
- 多模态纪要生成：在执行过程中，系统会自动截取关键节点的图表快照，并将节点判定结论汇编成册。最后由 LLM 进行自然语言的润色，输出一份结构化的《诊断分析纪要》（包含起因、排查过程图表、特征结论和维护建议）。
在实际落地时，最容易卡在“原子技能库（Skills）”的定义与边界划分上，如热力性能劣化（如效率下降、部件老化追踪），转子动力学类的突发性振动故障排查，大量的细节需要量化。
同时，要让用户能理解并修改规则，同时不破坏自动化流程，关键在于 RAG 内部的规则表示层。规则并非硬编码在技能逻辑中，而是以结构化文档的形式存储在知识库里：既对人可读（方便运维人员查看和编辑），也可被机器检索（让 RAG 在正确步骤注入正确规则）。
当专家修正 Agent 的结论（例如，调整特定故障类型的分析窗口）时，修正会被标记为高置信度样本记录下来。随着时间推移，RAG 会优先检索这些样本，在不重新训练 LLM 的情况下，让 Agent 学习到专家的判断逻辑。这就是架构图左侧展示的全场景、全流程记录循环：每一次操作都会反馈给 RAG，让后续分析越来越精准。
语音交互则体现在输入和输出两端：语音转文字为 Agent 提供任务描述，文字转语音朗读结论，同时生成结构化的分析纪要文档。你可以点击图中的任意节点，深入了解具体组件的细节。
开放式架构提供统一仪表板
通过 OPC-DA（或OPC-UA）导出实时数据的底层振动数据存储库配合，可以实现跨不同系统的仪表板，并提供一个直观的界面，方便设备运维员。
数据从一套监控系统流出，并沿着两个方向流动：一个方向面向操作人员(左侧)，另一个方向面向运维专家(右侧)。面向运维专家的数据较为专业，采用波形图、频谱图和极坐标图等专业图表，难以为普通操作人员理解，需要将机械状态简化为仪表板，使复杂数据被简化为简单的提示和警报，一旦系统内置的智能自动检测到机械故障，这些信息便会立即生成。
诊断规则提供直观的用户界面，可供机械/工艺操作人员使用，无需设备专家也能轻松操作。通过采用折叠树状层级结构汇总所有机械设备的当前状态，采用多重严重程度级别(如六级)来确保足够的细分度(从极端至无故障)，并在系统内置智能检测到机器故障时，提供易于理解且可定制的提示信息。
仪表盘功能至关重要，它能以操作人员易于理解的方式呈现状态和信息。对于那些没有配备全职专业工程师解读警报和异常情况的场景，这一点尤为重要。仪表盘通过模拟专业运维分析师的思维和系统化的诊断方法，生成非专业人员也能轻松理解的警报和建议。当设备出现故障时，操作员可以获得关于故障原因、严重程度以及应对措施的自动化指导。专业工程师通过将专业知识融入仪表盘，并行应用于多个工厂和成百到上千的设备，一位专家（或团队），能从繁琐的手动数据审查和分析中解放出来，自动检测问题，使专家能够专注于解决问题，而不是在寻找问题上花费大量的时间精力。系统有效地利用了专家（或团队）的内在知识，使他们能够同时出现在所有设备运行的场景。
仪表盘作为主页，用于组织、汇总和显示后台运行的诊断规则生成的信息，汇总诊断规则的输出（结果/操作），使用户能够“一目了然”地查看系统中所有受监控设备的运行状态。仪表盘显示的“一目了然”视图可包含多个报告/窗口，其中包括受监控设备的总体信息（资产层级）、所选项目的诊断规则严重性信息（严重性摘要、设备、组件和/或规则详情）、所选项目的健康状况和状态信息（资产健康状态）以及所选项目的事件信息（诊断事件和系统事件）。每个报告/窗口都是动态且交互式的，可以根据用户选择的项目快速轻松地显示其他信息。
简单易用的图形化规则构建环境（低代码/无代码）
用于处理输入数据的诊断规则通过图形方式（低代码）创建，可添加并连接来自可配置函数块库中的各个模块，以生成相应的输出(结果/动作)。
规则的创建通用采用图形化方式，利用涵盖算术、统计、关系、逻辑、条件和时间函数的各种功能模块库。数学表达式可以通过算术、三角和/或对数函数的组合来创建。诊断规则单独配置包括事件日志记录到数据库（阈值和保持时间）、运行/更新速率（频率）、延迟/滞后（保持时间）以及严重性（严重程度）等属性。通过为规则分配诊断和纠正措施信息，在适当的时候显示给操作员，形成具体的操作指导。诊断规则经过设计、测试和批准后，通过被添加到操作系统（如windows）服务中，并在后台运行以持续评估传入数据。基于所开发的标准诊断规则和程序的模板，可批量化用于不同类型的机械设备。
异常检测
在工业物联网（IIoT）背景下，对复杂机器进行监测和诊断需要掌握如何从数据中识别故障或风险状况。这可以通过寻找特定特征（故障识别）或判断机器何时运行异常（异常检测）来实现。 对于复杂的机械应用，为所有可能的故障模式开发故障模型既不现实，也不太可能出现足够多的同类故障案例来证明这种努力是合理的。鉴于典型的工业可靠性要求在80%-90%以上，所采集的大部分数据都围绕着正常、健康的运行状态，而现有的参考模型或工程模型也主要针对定义正常运行。因此，在这些应用中追求鲁棒的异常检测是自然而然的。
异常检测是指在受监控信号中识别出意外值的过程。意外值可通过与基础模型或用户定义的阈值进行比较来确定，通常是两者的结合。基础模型可以是统计模型、机器学习模型、基于物理的模型，或它们的任意组合。
接下来以一个实例数据为例，详细介绍应用于工业燃气轮机的多种异常检测方法，涵盖多种算法类型，并探讨它们各自的优缺点。关于机器学习应用中基本术语的回顾，可参见[[1]Brownlee, Jason. 《机器学习基础概念》。2015年12月25日，machinelearningmastery.com/basic-concepts-in-machine-learning/ [2]Nabi, Javaid. 《机器学习基础》。2018年4月15日，towardsdatascience.com/machine-learning-basics-part-1-a36d38c7916]。
1 – 示例数据
假设一台燃气轮机正在满负荷运行，且过程由最高燃烧温度控制。进气冷却系统发生故障，导致环境温度在一段时间内升高，随后恢复正常运行，同时计算出的燃料流量出现轻微偏差。当冷凝水渗入电气系统部分区域时，电气设备便可能发生此类故障。
我们的目标是仅通过监测这三个参数，在包含负荷变化的数据集中准确检测出冷却系统故障。这个简单示例将阐明异常检测的关键原理，同时突出各种方法在工业设备应用中的优缺点。需注意，虽然这些数据是模拟生成的，但基于现场观测数据。
图 1：（上）显示了一个月的环境温度和透平入口温度。（下）：显示了一个月的燃料流量。
图1展示了一段数据，纵轴为进气温度和动力涡轮气体温度，横轴为燃料流量。当月第9天和第20天，涡轮机短暂处于部分负荷运行状态。相应地，同一时间段内燃料流量有所下降。第26天观察到了温度异常。
异常检测的简易形式为针对单个监测参数设置静态阈值或限值。虽然该方法能捕捉偏离预定义运行区间的偏差，但也可能因正常运行（而非设备故障）而产生大量误报。若直接对测量或计算参数应用静态限值，则建议数据分析专家仅对预期处于稳态的参数设置静态限值。 对于随时间变化的状态参数，静态限值设定过紧，会导致不可接受数量的误报；若设定过松，则可能导致检测遗漏，进而引发灾难性故障。
图1的上部和下部展示了静态限值的示例。燃油流量限值导致当月第9天和第20天出现异常误报，并在第26天出现漏报（即未检测到异常）。图1上部的静态限值设置考虑了现场环境温度的年度波动。 图1中的三个参数说明了使用静态限值进行异常检测监控时面临的一些困难和挑战。在此图的示例中，操作员经排查后会发现，这些警报并非异常行为，而是燃机气路温度与燃料流量之间物理关系的体现。但需注意，传感器故障并未触发任何警报。
2–异常检测的无监督方法
无监督方法通常广义上采用距离度量，典型应用场景是寻找聚类位置。聚类算法旨在识别数据集中的不同聚类如图 2，其中部分负荷、满负荷和系统故障点分别用不同颜色和标记标出。 我们采用两种流行的机器学习方法——K均值（KMeans）和DBScan，在不检测负荷变化点的情况下，识别异常的系统故障点。当出现未知聚类点时，即判定为异常。
图 2：参数依赖性及数据聚类的可视化。
聚类只能对明显的聚集点进行分类。
KMeans
鉴于聚类对形状特征要求比较高（这是 KMeans 算法的已知弱点 [3]scikit-learn，“2.3. 聚类”Scikit-Learn，2018年，scikit-learn.org/stable/modules/clustering.html），预计 KMeans 算法表现不会理想。运行该算法时，必须指定要寻找的聚类数量，我们将其设为三个。
图3展示了KMeans模拟的完整结果。图的上部显示了分配给三个聚类的点数，分别命名为“最大”、“中等”和“最小”。请注意，最小聚类的点数始终为31，这恰好是负荷变化点的数量。在1000次具有随机起始点的模拟中，结果始终以相同的聚类划分结束，仅聚类标签名称的顺序有所不同。 图 3-1.1 和 3-1.2 展示了一次模拟的可视化结果，其中各聚类已进行颜色标注。在此，黄色代表“最大”聚类，绿色代表“中等”聚类，紫色代表“最小”聚类。 图3-2.1和3-2.2展示了另一组模拟结果。请注意，标签虽已改变，但聚类本质上保持不变。在所有KMeans模拟案例中，负荷变化均被识别为一个聚类，但系统故障数据未能被识别为独立的聚类。
在所有 KMeans 模拟案例中，负荷变化均被识别为一个聚类，但系统故障数据未能被识别为一个独立的聚类。 |
图 3：KMeans 模拟结果。颜色对应最终分类。（上图）显示了 1000 次随机起始点模拟的聚类数量。（中图/下图）显示了最终聚类结果的两次迭代。
DBScan
接下来，我们用广受欢迎的DBScan方法。DBScan方法受聚类形状的影响要小得多，因此预计聚类结果会更好。在实现该算法时，对半径参数 ε 以及每个聚类的最小样本数参数进行了调整。DBScan 算法与 K 最近邻算法 [4]scikit-learn，“1.6. 最近邻。”Scikit-Learn，2017年，scikit-learn.org/stable/modules/neighbors.html相似，但经过修改后成为一种无监督方法。DBScan 模拟结果如图 4 所示。
图 4：DBScan 网格搜索结果。（上）唯一聚类和标记为噪声点的计数对数 y 坐标图。x 轴值的增加对应于 epsilon 参数的增大。在每个数据集中，epsilon 保持恒定，而最小样本数逐渐增加。（中/下）具体的模拟聚类结果。需注意，聚类标签“-1”表示算法输出的噪声点。
图4的上图展示了DBScan算法识别出的唯一标签数量及被标记为噪声的点数的变化[5]scikit-learn， “2.3. 聚类 2.3.7. DBSCAN。” Scikit，2018，scikit-learn.org/stable/modules/clustering.html。随着ε的增大，聚类数量如预期般减少至1。对于每个ε值，均涵盖了一定范围的最小样本量。图4中的图表是特定情况下的聚类可视化结果。所选示例显示了聚类识别结果的巨大差异及其对输入参数的高度依赖性。
无监督方法分析
在KMeans案例中，我们从未观察到对异常数据的成功分类。这主要是因为部分负荷数据看起来比系统故障“更”异常。数据分析专家可以通过多种方式对数据进行预处理或后处理，以尝试获得更准确的结果。此外，设置准确的初始条件也有助于提高准确性，但在涉及大量不同类型机器的机群中，由于无法事先确定准确的初始条件，这种方法可能难以扩展。
在 DBScan 案例中，我们发现当 epsilon 值和最小样本输入对数量设定得当，结果显得更为合理。至少在案例 2（图 4-2.1 和 4-2.2）中，系统故障点被识别为与大部分运行点不同。然而，这些点中的大多数连同大部分部分负荷点最终都被识别为独立的聚类（请注意，此示例中识别出了 36 个聚类）。 经过适当调优并结合后处理的 DBScan 实现方案，可作为异常行为的初步预警，但很可能产生大量误报。因此，要成功应用该方案，仍需领域专家来验证检测点的有效性。
经过适当调优并结合后处理的 DBScan 实现方案可作为异常行为的初步参考，但很可能产生大量误报。 |
若要成功将无监督算法应用于工业物联网（IIoT）设备的异常检测，数据分析专家至少需了解复杂的物理关系（或咨询领域专家），以便选择合适的特征并应用相关方法，从而避免产生过多无法接受的误报。这些关系的考量可基于物理方程和已知的科学关系。 当此类信息不可用时，若数据量充足，数据分析专家可构建经验模型。然而，一旦这些关系被明确并理解，通过构建能够学习或掌握这些关系的模型来加以考量，可能会更为简便。这便引出了监督学习方法。
为了准确识别工业物联网（IIoT）数据集中的异常，数据分析专家必须考虑所包含特征之间的已知物理关系。 |
3–用于异常检测的监督学习方法
有监督方法相较于无监督方法具有优势：它们拥有可用于训练（拟合）过程的响应（目标变量）。此类数据集被称为标注数据，而用于训练无监督方法的数据集则称为无标注数据集。无监督方法与有监督方法的区别类似于开环控制与闭环控制的区别。 无监督方法类似于开环控制，而监督方法则类似于闭环控制。闭环控制中的反馈机制能极大提升控制目标的实现效果。同样地，响应变量为监督方法提供了关于预测质量的反馈。训练监督模型正是利用这种反馈来提高预测准确度。
要应用基于监督学习的方法进行异常检测，我们需要监控观测到的响应变量（燃油流量）与其预测值之间的误差，这一过程称为误差跟踪。通常，误差信号会通过后处理进行滤波，消除多余的信号方差。在本示例中，将采用移动平均法、多变量线性模型和多层神经网络模型来展示该方法。关于将监督学习方法应用于工业物联网（IIoT）设备的异常检测的其他演示，可参见[6]Flovik, Vegard. “如何利用机器学习进行异常检测与状态监测。” Medium, Towards Data Science, 2018年12月31日, towardsdatascience.com/how-to-use-machine-learning-for-anomaly-detection-and-condition-monitoring-6742f82900d7. [7]Allen, Cody W., Chad M. Holcomb, and Mauricio de Oliveira. “基于降秩线性引擎模型的故障检测。”ASME涡轮机博览会2016。
线性岭回归（Linear Ridge Regression）
在拟合线性模型时采用岭回归，以帮助减少训练阶段的过拟合[8]scikit-learn。 “1.1. 线性模型 1.1.2. 岭回归与分类。” Scikit-Learning，2018，scikit-learn.org/stable/modules/linear_model.html。将前15天的数据作为训练数据集，后15天的数据作为测试数据集。结果如图5所示。图的上半部分显示了原始数据以及预测数据。图的下半部分显示了原始预测误差、经过滤波的误差以及检测限。 当滤波后的误差超出限值时，即检测到异常。限值是根据图6所示的训练预测误差选定的。
图5：岭回归示例。（上）训练和测试的原始数据及预测结果。（下）原始预测误差、滤波后的预测误差以及检测限。
静态阈值选择过程基于误差分布。该误差分布应服从正态分布且均值为零。若不符，则表明模型不合适，或特征未能完全捕捉潜在过程，或两者兼而有之。有时，可通过变换误差分布使其更接近正态分布，此时即可计算出偏差较小的阈值。 “接近到什么程度才算足够”是数据分析专家必须做出的判断，通过反向变换可获得用于误差信号的限值。该过程如图6所示，最终限值见图5底部。在此案例中，限值之间的差异相对较小，但与对未知分布盲目应用均值和标准差计算相比，这是一种良好的统计实践。
图6：（左）岭回归原始训练误差分布。（中）转换后的训练误差分布及新限值。（右）采用转换后限值的原始分布。
基于训练误差分布，数据分析专家可以选择如何设置阈值，以及应追踪原始误差信号还是经过过滤的误差信号。 |
之所以使用过滤后的误差信号，是因为它们能平滑数据，并有助于减少误报。在训练数据集中，部分负荷工况已得到充分考虑，且过滤后的误差完全在阈值范围内。在测试数据集中，部分负荷工况下的燃油流量预测是比较准确的，且过滤后的误差完全在阈值范围内。此外，系统故障现已成功检测到，在过滤后的误差信号突破了阈值。
神经网络
现在我们考虑一个（多层感知器）神经网络[9]scikit-learn，“1.17. 神经网络模型（监督学习）。”Scikit-Learning，2019年，scikit-learn.org/stable/modules/neural_networks_supervised.html。训练过程与岭回归情况相同，只是神经网络的训练涉及的输入变量要多得多。训练阶段产生的预测误差在均值为零的中心呈对称分布。其方差略小于正态分布，导致峰值更高且尾部更窄，但该分布接近正态分布，因此我们省略分布变换，不再展示分布图，而是调整用于设定阈值的标准差乘数（the multiplier on the standard deviation）。采用乘数为3的岭回归情况相比，鉴于方差较小，们选择使用乘数为4，结果如图7所示。
图 7：神经网络示例。（上）训练和测试原始数据集及预测结果。（下）原始和过滤后的预测误差以及检测限。
神经网络的结果与岭回归相似。两组部分负荷数据均被纳入验证，未被滤波误差检测到，而传感器故障则被滤波误差检测到了。
监督学习方法分析
在回归和神经网络两种情况下，部分负荷运行均未触发警报，而系统故障则触发了警报。虽然这些结果达到了目标，但其获取过程较为繁琐。
使用监督学习方法进行异常检测需要基于标注数据进行训练并进行后处理。通常，工业物联网（IIoT）数据在采集时不会自动分类，因此实施监督学习方法需要对数据进行后处理以获取有用的训练数据。如果训练数据未能涵盖绝大多数的运行范围，则很可能发生误报。根据我们的经验，应用监督学习方法进行异常检测虽然在初始设置阶段往往需要投入更多精力，但在实际部署后能实现更高的检测准确率和更低的误报率。
如果训练数据包含异常运行情况，预测准确率可能会大幅降低。 |
4– 数据驱动模型的选择原则
通过示例数据集展示了异常检测的多种应用，并突出了每种应用的相对优缺点。虽然仅简单地探讨了基于机器学习的异常检测，但希望能阐明数据分析专家在针对工业物联网（IIoT）数据源实施异常检测解决方案前必须做出的部分决策，有以下原则供参考：
当参数未处于稳态时，针对单个测量值设置静态阈值将导致较高的误报率。需要具备系统专业知识并投入时间，对完整数据集的分析结果进行评估，以确定检测结果是否为有效的异常。
无监督聚类模型虽能有效检测异常点，但也可能将非异常的已知关联误判为异常，从而导致较高的误报率。数据预处理和启发式措施有助于降低高误报率。无论如何，系统专家都应审查结果，以确定检测结果是否为有效的异常。
有监督模型能有效识别已知关系，并结合错误追踪功能，可准确识别异常行为。若数据量充足，足以学习正常运行特征，则错误追踪的误报率将很低。虽然仍建议由系统专家进行复核，但可以高度确信检测结果为真实异常。
值得注意的是，无监督方法也已成功应用于错误跟踪流程，取代了静态限值的用法。总体而言，结合使用监督和无监督方法，通常能在检测准确率与最小化误报率之间实现最佳平衡。
监督学习模型能够有效识别已知的关联关系，并与错误跟踪相结合，可准确识别异常行为。 |
在成功实施全机群异常检测解决方案时，另一个必须提及的关键要素是，需要建设稳定可靠的用于远程数据采集的硬件条件，以及处理数据流、计算、警报通知和解决所需的必要基础软硬件设施。仅在单台计算机上使用少量数据进行异常检测的孤立案例，并不符合异常检测解决方案的标准和要求。虽然这不在本文的讨论范围内，但实施异常检测系统必须关注这些内容。
在电厂、OEM诊断中心，一般拥有来自各地的海量机组数据，通过状态监测系统收集并存储了多年，即便是这些历史数据绝大多数是在设备健康、正常运行期间收集的，通过诊断服务，可以大大提高设备的可靠性和可用性。此外，机组的诊断服务也会对受监控设备的运行数据进行分类、标注，以便进行进一步的训练和优化。
将工业物联网（IIoT）数据与系统专家提供的运行状态分类相结合，是OEM异常检测解决方案的一大优势。 |
这些数据结合数据分析专家和工程师的专业知识，使得OEM能够打造出一流的异常检测系统，进一步提高设备的可用性和可靠性，同时提升投资回报率。
5-优化报警平台和数量
在“异常检测”的状态监测方法中，用正确的软件报警来补充硬件及控制系统报警至关重要。
从太少到太多
早期的监测硬件通常只有一个报警设定点，但用户和制造商很快意识到这种方法并不完善，他们发现至少需要两个设定点：高（有时称为“HI”或“跳闸前”）和危险（有时称为“HI HI”或“跳闸”）。虽然只有一个设定点总比没有好，而且也可以用于跳闸，但这种方法意味着无法发出跳闸前警告，因此也无法指示应采取纠正措施来完全避免跳闸。
这款振动监测器可以追溯到20世纪60年代末，它只有单一的设定点。如今大多数监测器至少有两个设定点：警报和危险。
相反，如果仅使用单一设定点发出警报，操作员虽然可以在故障达到破坏性程度之前获知故障情况，但如果故障迅速恶化到人为干预无法阻止机器故障时，则无法自动保护机器。比如推力轴承故障可能在几秒钟内造成灾难性损坏，远超人类的感知和反应速度。
一段时间以来，随着微处理器在仪器仪表领域的普及，风向发生了转变：硬件开始支持多种报警设定点。这些报警往往不仅仅是基于液位，而是代表了复杂的逻辑组合和数学运算，例如平均值和变化率。尽管这些努力的初衷是好的，但它们常常导致在看似“正常”但实际上偏离稳态条件的情况下出现大量错误报警。
例如，当机器停机时，快速变化的振动水平触发的速率变化报警器会发出警报。虽然此类报警器在稳态条件下确实有效，但在机器转速变化（例如停机转速曲线）的情况下则无效。因此，报警面板会充斥着大量虚假指示。或者，工艺条件可能会发生变化——例如压缩机中气体的摩尔质量或发电机的负载变化——振动可能会迅速过渡到“新的正常”水平。虽然这种变化速率在稳态条件下可能异常，但它可能完全符合运行条件的正常变化，因此无需担心。
通过这两个简单的例子表明，随着系统中报警数量的增加，必须谨慎。当报警功能在硬件层面实现时，这一点尤为重要，因为操作员通常会在报警面板和/或DCS屏幕上看到这些报警信息。如果操作员开始遇到过多的误报，他们就会产生一种适得其反的怀疑态度，认为报警必须先经过验证才能采取行动。因此，他们的第一反应会是“仪表故障”，而不是“机器故障”。
像这样的报警“确认”按钮在过去的控制室面板上非常常见，现在很多工厂仍然可以看到。如果操作员因为认为报警是“干扰”或“虚假”的，而非合法的确认，说明这种报警策略已经失效。
一位业内资深人士回忆起，多年前的一个控制室，当时操作员们为了应对虚假警报，竟然用冰棍棒顶住警报确认按钮。虽然这只是一个极端例子，但它足以说明，一旦对警报的可靠性失去信心，工厂的警报系统就形同虚设，即使出现警报，也会被当作虚假警报而忽略。
报警设置于硬件、控制系统还是预测性维护系统?
首先，警报器应该安装在哪里？如果警报符合以下两个条件，则硬件是合适的安装位置：1.该硬件能够产生所需的测量结果。2.生成的警报需要操作员干预（而不是维护干预）。
举一个简单报警示例。假设监控一台水轮发电机，该发电机在启动和调节叶轮导叶时会经过“粗负荷区”（RLZ）。这是一个机械故障的例子，其表现并非简单的整体（未经滤波的）振动水平升高。运营商和OEM 已经了解到，粗负荷区在除 1X 频率（即与轴转速一致的振动频率）之外的大多数频率上都表现为宽带振动。
一种名为“NOT 1X”的测量值通常用于检测粗负荷区域，操作人员会主动使用此读数，以确保机器不会长时间处于粗负荷区域状态。此测量值满足两个条件：它可在硬件（例如TSI通道）中使用，并且操作人员会使用该读数来调整机器的运行状态。
为了进行对比，我们来看一种不一定适合硬件实现的报警类型：排气扇由于叶片上积聚颗粒物而频繁出现不平衡。虽然大多数振动监测硬件可以同时提供 1X振动幅度以及整体振动值，经验表明，1X振动幅度的上升几乎总是与颗粒物积聚有关，无需担心。如果及早发现，只需安排维护人员清洁叶片，即可恢复风扇运行。
操作人员无法对风机进行任何改动来应对这种情况，因此，即使理论上可以在硬件层面完成测量，但该位置发出的警报也无法为操作人员提供任何有意义的指导。而此类警报更应该发送给运维人员、旋转机械分析师或振动分析师。振动分析师首先会查看相关数据，以确保1X振动的变化由不平衡引起，而非其他故障，验证无误后，分析师会发出工作指令，要求维护人员暂时停止风机运行，以清洁叶片。
硬件报警与软件报警（控制系统、预测性维护平台）的另一个区别在于可见性和延迟。如果操作员需要在实时或准实时环境下依赖报警来对机器采取干预措施，那么硬件报警通常更合适，因为它们能够快速检测和发出警报。相比之下，如果软件报警的延迟哪怕只有 15 秒，这是因为复杂的规则需要计算时间，然后通过 Modbus、Profibus 或 OPC 等数字协议传输到 DCS（DCS 的扫描时间以秒而非毫秒计算），而 DCS 的扫描时间是以秒而不是毫秒计算的，那么对于操作员来说，这样的延迟可能确实难以接受。如果再传送到服务器，经过定时编排任务计算，再通过复杂的通讯和软件逻辑处理，延迟程度呈几何级数增加。
设置多少个警报才算太多？
一般来说，每个配备硬件报警的参数都应配备相应的软件报警，以便旋转机械操作人员在硬件报警触发之前就能了解某些状况，例如径向振动过大或推力位置异常。这正是我们所说的“低报警阈值管理”，因为振动分析师或旋转机械工程师可以及时发现那些可检测且呈不良趋势的问题，但这些问题尚未严重到触发硬件报警的程度。这样一来，他们就能采取积极主动的措施，在问题恶化之前找到根本原因并加以解决。
如果单个警报不足以起到作用，但过多的警报又会适得其反，那么“合适的”警报数量是多少？
除了控制软件提供“预警”级别，状态监测软件中为保护系统未测量的参数提供额外的报警级别也十分有用。例如，一个滚动轴承，从最早的预警信号（即滚珠旋转频率 (BSF)、内圈滚珠通过频率 (BPFI) 或外圈滚珠通过频率 (BPFO) 的振幅增加）出现到失效，通常需要 6 个月的时间。由于故障间隔（PF interval，从检测到功能失效到功能失效的时间）足够长，因此采用基于软件的方法来预防故障是非常合适的。
虽然采用滚动轴承的机器可能需要基于整体振动水平的持续保护，但并不一定需要针对每个轴承相关频率设置硬件报警。因为经验表明，此类故障通常是逐渐发生的，而非突然发生的。对于特定机器，对整体振动、轴承温度、润滑油温度和润滑油压力的保护参数可能更为必要，因为任何这些参数的测量值超出正常范围都可能预示着即将发生突发性故障。
因此，基于软件的报警系统的指导原则归结为两个问题：
1. 哪些辅助警报可以有助于更主动地发现任何正在发展的问题，并防止其发展到硬件警报级别？
2. 这些警报会误报吗？是否可以更可靠，能够在合适的时间（既不太早也不太晚）安排维护或其他干预措施？
如果软件报警能够满足上述两个条件，那么它就很有用。因此，无论是两个软件报警还是二十个软件报警，只要能起到主动预警作用，都无关紧要。选择满足目标的最小数量，这样一来，维护报警设定值本身就不会成为一项繁琐的工作。
软件功能的优化
即使测量数据源自硬件，也不意味着其报警也必须源自硬件。某些测量数据可能完全不需要设置相应的硬件报警，完全可以通过软件来实现功能更强大的报警，对直接测量的测点、计算的测点以及“虚拟”测点进行报警。虚拟测点是由两个或多个其他测点组合而成的复合测量值，例如，它可以是多个直接读数的平均值。又例如，它可以检测三个条件是否存在，当所有条件同时存在时为“真”，当所有条件不同时存在时为“假”，典型的如T3温度，通过数学和逻辑运算，几乎可以不受限制地发挥想象力。
状态监测软件通过可折叠的树状层级结构汇总所有机械的状态，使用多个严重级别来实现足够的粒度，从极严重到无故障，并在系统检测到机械故障时提供易于理解且可自定义的建议，大大有助于运维能力的提升和降本。
进一步通过对状态监测数据的灵活建模，可以创建更多强大的报警，通过智能消息传递为这些报警赋予意义和上下文，从而指导人员了解报警的严重程度、报警位置和报警响应，为运行和维护人员提供智能建议。
关于状态监测+故障诊断领域的技术交流和合作，欢迎扫码报名：
https://f.wps.cn/g/XC9qVcNF/
注：精力有限，部分内容源自AI、工具和人工翻译，不一定严谨，也未仔细的校对，有错误欢迎留言指正，原创内容，翻译、整理和撰写不易，请共同维护网络文明和环境，不允许擅自转载和发表！
本人计划建立一个燃机领域交流群（也可以是航机、航改机等设计和运维领域），为了保持一定的纯粹性，需经过验证相关背景后才能通过，若有兴趣请扫描报名。
https://f.wps.cn/g/fP2SWBK4/
