智能运维大数据的终极宝典（附图表解析）

一、何为智能运维 ?

生产设备/装备是工业的重要生产工具，其可靠性、性能对工业生产有重大影响。随着工业大数据推进，设备的智能运维被定义为一个重要的应用领域。但何为智能运维?目前还没有一个明确的定义，但有不少提法，我们将其初略归纳为4种模式：

♦ 智能决策，如预测性维修、故障诊断等PHM、运维运作优化;

♦ 智能装备，将云端分析结果直接作用到端(如传感器偏差矫正);

♦ 新业务模式，如共享备件库存等;

♦ 结合其他新兴技术的新能力(如基于无人机的自动巡检、基于AR的协同运维)。

智能运维运维只所以很难给出一个明确定义，是因为运维业务涉及的维度复杂性。下图我们从业务用户、过程环节和业务目标3个维度去描述，不同维度组合决定了智能运维的内涵的不同。我们可以广义认为只要能够提高运维业务目标的措施都可以称为智能运维。

 

 

以用户角色为例，设备制造商与业主的动机不同。设备制造商主要从降低事故损失(包括直接损失、生产影响/产品形象等间接性损失)角度去看，落在预测性维修、提高维修效率(或降低MTTR)等方面。业主(生产企业)主要从保证生产连续性(或提高设备OEE)的角度去看。即使在同一个生产企业内部，生产运行部的关注和设备部也有微妙差别，生产运行部更加关心生产的稳定性和连续性，而设备部则关注设备延寿、设备状态维修和维修效率。

二、大数据平台能提供什么?

智能运维通常涉及到大量装备的高频传感数据(机器状态、工况等)以及丰富的上下文信息(环境、运维等)，属于典型的工业大数据应用。除了大数据平台的共性需求之外(提供动态接入、质量在线处理、时序数据压缩与索引等数据存储，以及并行化计算功能)，智能运维还有不少工业设备的特有需求。下面从行业数据模型、行业算法、行业知识库三个角度进行阐述。

行业数据模型：设备全生命周期档案

设备智能运维的一个前提就是设备的全生命周期档案，记录设备的过往今生以及不同维度的信息。这是大数据应该解决的基础问题。包括设备结构(BOM)、维修履历、故障记录、异常预警记录、工况、档案、基本信息等维度。

 

 

设备全生命周期档案，不仅仅是多个数据源Data Schema层面的关联，还包括业务语义层面的处理，包括编码间的映射关系(例如，设备编码规则改变前后的对映)、同义词(例如，风速在不同时期数据标准中的字段名可能不同)、字段名称相同但业务语义不同(以油气生产中的“产量”为例，井下产量、井口产量、集输产量等不同口径的“产量”，因为测量方式、测量环境、测量标准不同存在很大差别)。大数据平台在提供行业建模工具时候一定要注意业务语义层面的需求。

以设备档案数据模型为基础，大数据平台提供基于图搜索技术的语义查询模型，以友好的方式支撑设备管理分析。以风机为例，当叶片断裂事故发生后，整机制造商运维主管想查看确认是否为叶片批次问题(即和当前风机使用同一叶片厂商的风机最近机舱加速度是否正常?)，有了图语义模型的支持，后台可以自动跨越多个表格进行查询(而不需要用户/应用开发者写复杂的表间关联语句)，这样将大大降低应用开发的工作量。

 

 

行业数据模型：工业知识图谱

在设备运维中，除了设备档案数据，通常还存在大量的故障案例、设备维修过程记录等非结构数据。这些记录中蕴含着大量的故障征兆、排查方法等实操经验，对后续的运维有很大指导和借鉴作用。通用的文本分析，由于缺乏行业专有名词(专业术语、厂商、产品型号、量纲等)、语境上下文(包括典型工况描述、故障现象等)，分析效果欠佳。这就需要构建特定领域的行业知识图谱(即工业知识图谱)，并将工业知识图谱与结构化数据图语义模型融合，实现更加灵活的查询。

行业分析算法：已有分析资产(Matlab/Python/R)的并行化

大数据平台也需要支持已有分析模型的快速成熟。在大数据兴起之前，企业就开发了不少基于Matlab/Python/R语言的单机分析模型，只不过缺乏大量数据验证。经典的大数据并行化系统(Map-reduce)要求重新编写分析程序，但通用平台算法库(如MLib/Mahout)对工业分析的分析函数(比如，信号处理、系统辨识)支持有限。而在很多工业分析场景中，记录间存在着时序关系，并行化分组通常是有明确业务语义的字段(比如，风功率曲线计算是按照风机、月份进行并行化)，而不是记录条数。因此，工业大数据平台应该支持非侵入式的Matlab/Python/R并行化，用户只需指定可并行化的数据字段，对单机分析程序做简单适配之后，就可以直接甩到大数据平台上做全量并行化，通过大数据的迭代，去伪存真，探究海量数据后面的一般性规律，实现企业已有分析资产和实践经验的快速变现。

行业分析算法：工况特征库与时序分析算法库

在经典分析算法库(包括深度学习)和非结构化数据(文本、音频、图像/视频等)算法的基础上，提供设备故障和运行状态分析所需的特征库或算法库。

针对工况时序数据，提供时序切割、时序分解、时序聚类、时序聚类、典型模式挖掘等共性分析算法。

动力学系统分析所需的算法(系统辨识、ODE仿真等)。

针对典型工业单元(如电机、齿轮箱、反应釜等)的FTA(Fault Tree Analysis)，包括典型故障类型、特征变量，以及故障的研判方法。例如，对高速旋转部件的振动分析算法库(时域、频域和时频分析)。

 

 

行业知识库：故障诊断/运维案例库

针对典型设备的故障诊断和运维，企业和社区通常存在着大量运维工单、经验总结报告、社区讨论等。基于工业知识图谱分析和行业专家的梳理，形成针对特定领域的案例库，并形成半结构化的维度标签，方便检索和语义推理。

 

 

行业知识库：诊断模版库

针对典型设备的故障诊断，形成诊断模板，并与设备资产档案字段关联。在应用开发时，只需要数据实例化，就有了60～70%的成熟度，后面只需要根据实际数据和特定控制逻辑做一定定制化。

 

 

三、智能运维大数据分析的CRAB规划方法

正如第一节讨论，不同行业、不同设备、不同角色企业的智能运维差异很大，在智能运维的实践中，我们初步归纳出CRAB四部法。在规划上，运维大数据相对质量大数据要轻松一些，因为设备运维与生产工艺的耦合度没有质量分析那么大，且设备通常有很多共性基础单元构成。

 

 

业务上下文(Context)理解

业务上下文包括如下四个方面。缺乏这些基本面的把控，智能运维大数据分析很容易与业务脱节。

 

主导企业的资源能力（Resource）分析

主要从如下三个方面进行分析：

(1)主导企业在产业链中的独到能力：决定了智能运维的侧重点在什么地方。

不同设备特征(机理/结构复杂度、失效模式、数字化程度)、不同角色的知识/信息资源程度也会决定智能运维的着力点。对于比如风力发电机、航空发动机等主力生产设备，并且生产过程也是透明的，则设备制造商可以掌握大量类似设备的数据，从而在数据技术和知识基础较业主有很大优势。但对鼓风机、机床等装备，只是生产制造设备中的一环，设备制造商即使可以掌握设备自身的状态信息，但对整个生产的工况、生产控制、工艺以及其他相关设备状态缺乏了解，设备故障预警对设备制造商来说有一定的限制。因此，在进行设备运维业务规划时候，要充分了解业务上下文(Context)，决定了智能运维的侧重点在什么地方。

(2)数据资产

在了解相关IT系统(SCADA、MRO等)基础上，还应该从CPS(Cyber-Physical System)思维的角度，去审思Cyber在多大程度上反映了Physical?在哪些地方有较大差距?这就需要

♦ 逻辑层面的融合：在了解设备的数字化程度之上，将IT系统中的数据与设备动力学机理、控制逻辑、环境、工况、生产控制等信息融合起来，去看现实世界中的例外情形。比如，MRO订单中写的保养项在大多数情形下是否忠实执行(用明确的数据记录，但不一定真实);备件需求是否存在囤货行为(永远不会有明确的数据记录，但切实影响到了备件销售量的这个数字)。

♦ 数据的场景化：在数据中重现所有业务场景，更直观地了解这些场景下数据的分布和走势。如下图所示，当风机重启或个别变桨PLC重启时，可以在数据中清楚地看出桨距角的初始化过程。

 

 

同时，也尽力去发现业务访谈中没有提到的“异常”场景。以下图为例，在早期业务访谈中，大家一直认为低风速下风机应该处于停机状态(桨距角在90度左右)，但实际数据表明，低风速下风机也可能处于待机状态。这对于业务人员来说是默认的常识(但发生频度低)，故而早期业务访谈中客户没有提及，若数据探索不够细致，这样的风险将传递给后续的建模环节。

 

 

♦ 技术领域常识对数据能力的基本指导：在如下所示的P-F图，给出了在不同失效阶段，哪些表征量(红外、振动、油质、声波、温度等)是显著的。可以给大家一个基本面的判断，消除很多不必要的“幻想”。

 

 

source:https://production-technology.org/tag/probability-of-an-injury/

(3)行业经验与知识

对于不少问题，一线业务人员或行业专家已经有了相对清晰的认识，这时候没有必要走纯粹数据挖掘的思路。但大数据仍有很多价值，因为很多专家经验通常不够精确(模糊、歧义、不完备、多个逻辑间的冲突)，大数据平台通过支持“大-小数据”迭代，快速支持行业经验在全量数据上的验证与精化。

针对典型的设备故障以及诊断的问题，大数据平台或数据分析案例库通常积累了很多故障模式、故障原因、故障因素/表征以及常用的诊断模版，但FMEA(Failure mode and effectsanalysis)、FTA(Failure Tree Analysis)经典方法对于细化一个具体设备的故障模式很有帮助。

 

 

针对典型的设备故障以及诊断的问题，大数据平台或数据分析案例库通常积累了很多故障模式、故障原因、故障因素/表征以及常用的诊断模版，但FMEA(Failure mode and effectsanalysis)、FTA(Failure Tree Analysis)经典方法对于细化一个具体设备的故障模式很有帮助。

业务模式与技术方案(Analysis)设计

主要包括如下3个方面。技术方案设计在前面质量大数据分析的文章中讨论过，这里不再赘述。

业务模式如何运作智能运维业务、如何度量成功

技术方案设计大数据平台设计、数据分析技术路线、应用设计

推进阶段推进阶段

在业务模式设计上，要从业务应用场景的角度去思考智能运维的业务需求。例如，有很多设备运维过程，虽然实现了远程“监视“(而不是“监控”)，但异常/故障判断仍然全部靠大量的人工，业务需求就是降低监视的人力工作量。该业务需求的技术方案从表面看起来是一套故障/异常自动研判系统(构建一个高精度的机器学习模型自动研判)，但若深一点思考，就会发现很多关键生产中要求“零误判、零漏判”。此时，“辅助决策”是唯一的现实方式。再深入一层，“辅助决策“又可分为2种方式：

♦ 机器学习模型研判供参考，人工终判;

♦ 构建一个自动研判模型(机器学习+行业经验)实现对相当大比例样本的100%精度的自动研判，其余的样本留给人工去判断。在很多实时性强或人力消耗大的业务场景，这种方式通常更受欢迎。

在技术方案设计上，同样要考虑到应用场景的需求与限制。例如，“云+端”是个很好的提法，但要考虑网络延迟、数据安全、模型稳定性等现实限制。

执行路线图(Blueprint)

根据课题定位，进行关键技术攻关，从模型的精度、稳定性等维度快速评价工艺落地的可行性。对于技术可行的课题，选择合适的产品类型和地点，进行控制性实验，最后进行大规模的应用推广工作(以及对应的大数据应用开发)。在分析模型投入试点之前，最好能够跳出技术，回归到业务角度进行再“再思考”,至少回答以下3个问题：

♦ 模型的应用场景：给谁用?对于预警/预测，提前量是多少?是否足够采取必要的干预动作?模型的漏报率、误报率对生产意味着什么?用户使用时倾向于的交互界面是什么(比如，在高空运维时，语音也许比触摸屏好)?

♦ 模型所需输入的可获得性：在模型运行时，这些信息是否能够全部获得?

模型的适用范围，以及例外情形处理策略：如果遇到未建模情形，如何处理?模型结果的Worst-case是什么?应对措施是什么?

四、总结

本文简要讨论了我们在应用KMX大数据平台实施智能运维项目中的部分经验与感想。和很多其他大数据应用一样，智能运维应从业务出发，将大数据技术融入到企业的运营与技术体系，融入的具体业务流程与环节。

 

标签： [db:TAGG]

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。