设备智能运维怎样落地？（下）

一径寒云

设备智能运维落地工作的七个步骤中，从数据探索到模型部署上线的工作属于数据分析范畴。从更宏观的角度来看，数据分析模型是将数据“持续”转化为价值的环节，因此也是整个智能运维工作中的关键环节。设备智能运维工作中的数据分析包含如下步骤：
智能运维中的数据探索

在正式进入模型开发前，首先要对数据情况进行检查、验证和处理。在研究性算法编制的时候，或实验条件下小规模数据处理的时候，几乎没有数据探索工作，因为边界和数据情况可控。但对于一个24小时*365天工作的设备智能运维的数据分析模型而言，首先要保证原始数据是否能满足条件，例如已有测点、数据质量等，并在此基础上最终确定模型可行性及算法方案。因此数据探索本质上就是一个可行性验证的过程。
数据探索工作主要包括两个维度的内容：
第一、数据质量的检查与处理。
这里所说的数据质量是从模型应用角度来进行的审查，而非简单的数据接入质量。一般包括如下两个大方面：
1、数据的完备性：是指目前数据是否足够支持解决目标问题。例如，某大型空压机驱动电机的智能运维所面临的数据源是电机的秒级振动幅值数据，该采样率是无法支持频谱分析的，因此只能对振动时域特性进行分析，但这样的数据依然可以构建一个可行的设备健康评估模型，给电机状态指向性的建议；但如果要想更加完善的评估设备状态、甚至进行深入的诊断，是需要很多高频采样的振动波形数据。
2、数据的可用性：数据的可用性是数据是否满足分析需求。其中包括数据的重复、空缺等。这些数据质量问题有时是数据的接存管用过程中产生的，有时候是传感器自身带来的。这些都需要在数据可用性检查中进行探知，以排除其对后续模型开发造成的影响。
第二、 数据关系的检查。
在业务理解的过程中，我们知道某些数据之间存在机理关系。数据探索的一个目的是对数据关系是否符合机理关系进行一些探索和检查。工业工程师所理解的数据关系都有一定的前提条件，而设备实际运行工况非常复杂，与实验室条件肯定有差异。当差异影响不大的时候，数据关系表现得十分明确；但如果工况、环境等影响较大时，数据关系就会受到明显干扰。此时需要考虑的是：这些数据关系的模糊，是多机理、隐变量叠加的原因，还是数据噪声的原因：不同的原因背后所对应的模型处理手法是不同的。
下图为一个水轮机组负载(电流)与振动的关系:


一般而言，工作负载大，振动也会越大；可这个图中电流与振动却是明显负相关。这是数据关系与简单机理不相符的一个例子。但是机械工程师们会想到，对于立式安装的水轮机组，在一定负荷范围内：负载变大时整个系统的刚性会增加，确实有可能导致振动幅值变小。这样一来就会发现，这是多机理叠加的结果，数据表现是正常的。如果不是实测，可能很多工程师在总结经验和数据关系时，会忽略“系统刚性”这个因素。这是数据探索中一个重要的功能，在数据上验证上一步“业务理解”的知识并进行修正和补充。
智能运维中的模型设计

模型和算法两个词经常被混用。从工程实施层面上，我们更倾向把算法当成是某种通用“计算方法”，比如加减乘除，神经网络、随机森林也是一种算法。算法是在描述数据之间的计算关系，而不关心数据本身的物理意义。模型则是对某个问题搭建的完整分析模式，例如设备智能运维模型；而搭建分析的过程中会用到各种“算法”，可能是复杂算法，也可能是基础的加减乘除和统计分析。
在设备智能运维领域，模型的分析对象是设备，而设备是工作在不同的工况下的，而每一个工况下设备的运行表现参数肯定会呈现差异；而这些差异并非来源于设备健康状态的变化，而仅仅是工况引起的系统性波动。因此，设备智能运维模型的第一步必然是设备的工况划分。
不论是使用标准的预测性维护理念，还是传统的阈值对比理念，评价设备状态总是要将设备实时状态与基准进行对比。因此界定基准是智能运维模型的第二步。显然建立基准的过程中是必须考虑设备工况的，因为不同工况下所监控的健康指标(例如温度、振动、效率等)的基准是不同的。最理想的模型当然是覆盖全工况的；但对于设备健康评估模型而言，有时只需考虑最常见的稳态工况也是可行的。
第三步则是如何对比设备实时数据与基准模型和进行健康评价，例如简单计算超过阈值的程度就是一种最简单的评价模型。但是，阈值比较容易受噪声影响，过高过低都不好，难以平衡误报率和漏报率；因此，一些基于概率统计的评价算法，例如基于广义似然估计的异常检测算法，可以更好发现故障早期的微小变化与异常。
在完成设备实时状态评价之后，工程师应该对每一个评价基于业务语义，并关联相应的业务动作，这样才能被现场的任用更加清楚地理解和使用。
除了分析模型构建上的设计，还需要配合数据接入、数据结构、数据应用原型等工程实施上所必须的设计工作，这个是和通常的软件开发流程一致的。
智能运维的模型实现

模型实现主要就是代码的编写和调试工作，但是工程代码与实验研究代码具有很大的差异，因为后者的使用场景与使用者有限。在工程实际中，分析模型的相关代码需要遵从软件工程的规范，处理很多实际的数据工程问题，并会被不同人反复使用或修改，因此代码的稳定性、可读性、架构等方面需要有整体考虑。除了对代码编写使用的规范，同时对代码读入和产生的数据也有一定的规范性要求。实际工作中，很多工业工程师都具备原型代码的编写能力，但在工程实现上还需从软件工程角度做一定要求。
在设备智能运维领域，还有一个常见的工程化问题，就是一个模型在什么时候需要调整？还是模型一旦建立就一劳永逸？一般而言，分析模型的建立是以一定的设备状态为基础的，但是当设备状态发生变化的时候，模型内部的一些关系就需要调整，常见的一种情况就是设备大修。一旦设备大修，设备零部件之间的各种关系就会有一些改变，例如各零部件之间连接刚性的变化。因此，每次用户对设备进行调整、维护的时候，就需要考虑这种调整是否影响模型。一般而言，如果设备的运行方式和数据源没有变化，模型只需简单的重新学习升级模型参数，无需从头开发。类比传统工程师的工作，大修后的PID控制器重新整定就类似于模型的重新学习，但无需重构整个控制系统。
智能运维的模型部署设备智能运维的模型部署除了数据平台和模型部署环境等IT基础设施有关的技术，还需要从设备状态评估的业务需求角度进行深入考查，如下几个问题：
● 模型多久运行一次?
● 每次调用哪些模型运行，模型之间的关联关系是怎样?
● 模型中间数据是否会被业务应用?
在日常的设备维护工作中，这些问题就相当于维护机制的确定。对于设备智能运维而言就是间隔多久对设备智能运维模型进行调用和运行?每次都对哪些参数进行计算、评估和分析?如果用数字点检的概念来看，就是计算机多久对设备进行一次点检，以及点检的内容。另一方面，智能运维模型的中间结果可能会被专家进一步使用，因此模型中间数据也需要按需存储和调用。一个常见误区是：模型都需要“实时”运行，问题就在于如何定义“实时”?一般工业现场对于关键参数都已有实时监控和报警系统，那健康评估模型无需重复造轮子，而更多是对已有系统的补充。在我们众多实践中，设备健康评估模型无需秒级运行，而是小时级、甚至天级的频度运行。因为通常的监控已实现了实时异常的报警，所以健康评估模型更多是从不同维度和长期趋势角度去发现设备的异常；而通常的用户使用方式也是由工程师每天进行依赖于模型的“点检”，而不是现场操作员的报警操作。
设备智能运维的最终落地

从数据分析角度来看完成了智能运维的部署，就已经完成了阶段性的任务。但是从设备智能运维本身来看，完成这一步工作之后，基本上就可以让一个智能运维的工具投入工作。关于智能运维系统的有效性等问题，在业务评估工作中完成，并进入下一步迭代之中。智能运维工作的落地就是在一步一步的执行，一次一次的迭代中最终体现出价值的，而这种价值的体现就是智能运维工作的“落地”。关于设备智能运维，最理想的落地期待就是系统一旦投入运行，马上实现设备智能运维的价值，简单来说就是提质、增效、降耗。但是，这样的目标是一个最终的目标，客观的说，一次性做到这样的目标是十分困难的，因此，可以把一个系统已经进入使用，并逐步迭代的过程，看做是落地的过程。落地的过程本身也是一个修正提升的过程，而使用价值的产生是在不断迭代提升之后出现的效果。