下载掌阅APP，畅读海量书库
立即打开
GRISP-DM方法论在工业领域的细化如图3-4所示。在CRISP-DM方法论的基础上，加入“分析问题识别与定义”这一步骤。
图3-4 CRISP-DM方法论在工业领域的细化
在传统商业数据分析中，假设分析课题是事先给定的，作为业务理解阶段的前置输入，分析课题通常由业务分析师（Business Analyst）或业务部门定义并提供给数据分析师（Data Analyst）。但在工业实践中，通常很难实现这样清晰的分工。
分析课题识别与定义首先要对行业和企业的基本面有全面把握（即上下文理解）；其次，充分利用行业参考模型（如质量管理中的PDCA、6-sigma等方法论框架 [2-4] ）、管理工具（如Value Chain Analysis等 [5-6] ）、分析方法（如5W2H、MECE原则等 [7] ），将业务需求转化为数据分析问题；最后，形成一个相对清晰的数据分析问题定义。
1. 上下文理解（Context Understanding）
工业系统涉及物理域（Physical，物理世界的运行规律）、业务域（Business，业务经营与管理）和数字域（Cyber，信息领域的刻画）。因此，工业大数据分析的上下文理解也要从这3个维度入手，将每个维度细化，并形成工业大数据分析的上下文理解框架，如表3-1所示。在数字域，可以分为概念、数据、执行3个层面，概念层面进行定性但全面的了解，数据层面从定量化的角度描述要素，执行层面回到物理世界，从落地的角度进行理解。对于一个具体问题来说，只有从不同颗粒度（至少从当前颗粒度、高颗粒度、低颗粒度）进行具象分析，才能在问题筛选与定义时做到收放自如。
表3-1 工业大数据分析的上下文理解框架
2. 需求转化漏斗（Requirement Translation）
在上下文理解的基础上，通过对比当前状况（As-is）与期望状态（To-be），基于业务理解、行业参考模型（如质量管理中的PDCA、6-sigma等方法论框架）、管理工具（如Value Chain Analysis等）、分析方法（如5W2H、MECE原则等），形成实现跨越差距的若干可行方案。需求转化的考量因素如表3-2所示。
表3-2 需求转化的考量因素
在分析问题选择方面，结合上面的Measurable、Feasible分析，采用“业务导向+数据驱动”的方式，得到需求转化流程如图3-5所示。从关键业务目标出发，按照SMART（Specific、Measurable、Attainable、Relevant、Time-bound）原则，分解并关联到具体业务领域（研发、建设、运行、运维、安全环保、销售、采购等），从重要度和紧迫度的角度，对可能的分析问题进行评估。结合初步因子分解，评估每个问题所需数据的完备性。综合业务价值和数据完备性，对多个问题进行优先度排序。
图3-5 需求转化流程
3. 分析问题定义（Problem Formulation）
分析问题定义主要包括以下方面。
（1）问题的业务类型：用1个短语（最多1句话）说明问题的业务类型。
（2）问题的技术类型及技术要求：用1个短语（最多1句话）说明问题的技术类型及技术要求，如表3-3所示。
表3-3 分析课题定义：问题的技术类型及技术要求
（3）业务场景包括正常场景和例外情形，业务场景示例如表3-4所示。
总结实际生产或应用过程中可能遇到的业务场景，这样分析问题及其结论才有实用性。
表3-4 业务场景示例
（4）当前分析问题的范围：覆盖哪些产品、地区和业务场景。
（5）数据列表：可以提供的数据类型、关键字段、数据颗粒度、时效性，以及可以提供的数据范围（如时间、空间等）。
在CRISP-DM方法论中，这一阶段从业务的角度理解项目的目标和需求，并将其转化为可解的数据分析问题，可采用业务流程建模、决策建模等方法分解业务目标、分析业务用例、找寻关键因素、确定分析问题的范围。
可以采用以下3种模型提高沟通协调效率。
1. 系统上下文模型（System Context Model）
在关键要素分析方面，工业大数据分析的上下文模型很重要，包括生产、运作、环境、时空等多方面的上下文。只有基于上下文模型，数字空间才可能部分反映物理空间。
（1）在设备后运维中，BOM（Bill of Material）是一个了解上下文的好起点。例如，在风电装备制造业，需要了解风机的工作机理、风电场的业务运作机制、设备的关键动作状态（如偏航对风、解缆、降功率运行、保养、故障停机等）。只有基于这些信息，才可能形成数字世界对物理世界的相对完整的刻画，如图3-6所示。
图3-6 数字世界对物理世界的相对完整的刻画
（2）在离散制造环节，可以以制造或装配工艺设计、生产管理（组织、计划、执行）、质量管理、关键设备管理（生产设备、检测设备）为主线进行了解。
（3）在流程中，PFD（Process Flow Diagram）、P&ID（Pipe & Instrument Diagram）这两类图很重要，可以帮助我们了解相关化学和物理过程，以及前后工艺环节之间的影响（如后续环节的反应速度会通过管道压力影响前置环节的反应条件等）。
系统上下文模型的主要内容如表3-5所示。
表3-5 系统上下文模型的主要内容
模型的表现形式多样，生物发酵罐控制流程图如图3-7所示，直观的表示更易于沟通。①对于微观的物理、化学、生物过程来说，动力学方程或因果关系模型可以更好地刻画主要因素及其关系。图3-7中包括输入量（可控量、外生变量）、状态量（可测、不可测）和目标量；②对于复杂装备，可以描述其组成关系、工作原理，以及各测点间的空间关系；③对于宏观的经营过程或生产、经济问题，描述背后的商业规则（如供需平衡、采购量折扣等）、基本规律（如季节模式、气温对燃气需求的影响等）和行业常识。天然气用量的驱动因素模型如图3-8所示。
图3-7 生物发酵罐控制流程图
图3-8 天然气用量的驱动因素模型
2. 系统动力学模型（System Dynamics）
系统动力学模型从概念层面刻画不同因素间的影响关系，把一个复杂问题“分解”为若干简单明确的问题。一个简单的判断原则是，如果不能将一个数据分析问题分解为10个因素之内的若干小问题，则意味着分析还不够深入。
对于一个“在技术上可行”的数据分析问题来说，在问题定义阶段一定可以归纳出如下3种前提中的一种。
（1）假设（Hypothesis）：基于机理或先验知识，猜测存在某种关系或规律，需要用数据证实或证伪。例如，在居民燃气负荷预测中，假设居民用气的主要构成是做饭、沐浴等日常生活需求，那么居民用气应该存在明显的时（周期性、季节性）空（不同地区、不同小区类型）规律，也会受天气等外部因素的影响。因此，数据分析的重点在于验证这些假设可以在多大精度上预测用量。
（2）不变量（Invariant）：问题中的不变因素或规律是什么。例如，在图像识别中，期望的性质有位移、旋转、尺度、形变不变性等，CNN中的层次卷积、激活函数、池化等处理手段恰好迎合了这些性质。
（3）动力学模型：对于物理、化学等微观过程，需要描述各量间的影响和转化关系（不一定用方程式）。例如，对于OLED功耗分析，可以采用类似FTA（Fault Tree Analysis）的方式逐层分解功耗的影响因素（如膜厚、材料等）。
在现实中，并非所有因素都可观或可控。从可观、可控两个维度刻画关键因素，得到因素分类如表3-6所示。
表3-6 因素分类
基于因素分类，形成分析问题的因子动力学关系图，系统动力学模型示例（区熔炉）如图3-9所示。对于外生变量（特别是不可观测量）来说，虽然我们无法直接对其进行优化，但其提醒了我们分析模型的适用前提。
也可以采用更简洁的表达方式，系统动力学模型示例（生物发酵罐）如图3-10所示。
图3-9 系统动力学模型示例（区熔炉）
图3-10 系统动力学模型示例（生物发酵罐）
3. 业务用例（Use Case）
工业分析问题定义的一个重要内容是回答谁来用、什么时候用、如何用等问题，业务用例是这方面的一个比较好的工具。在刻画业务用户、业务流程的基础上，分析业务对模型的核心需求，从而确定分析模型的度量指标。例如，在抽油机故障检测中，判断机器状态是否正常，若异常则给出故障类型。业务需求是降低一线监测人员的工作量，而不是实现简单的决策支持。对于这种场景，精度达到99%的分析模型也没有多大用处，如果无法指明哪1%是错误的，则需要进行全时的人工审查。还不如一个可以完全准确地排除30%的样本，其余的70%进行人工判断。也可以仅提供包含初判结果的模型，这样至少能够节省30%的工作量。这就是数据分析中常谈到的误报、漏报问题，与经典的N分类问题（N种状态类型，包括正常状态和N-1类故障状态）之间存在一点微妙的区别，现场运作允许分析模型输出N+1类状态（第N+1类是不确定状态），将前N类判别成N+1类的惩罚很小（可以进行人工处理），但前N类的误判是不允许的（模型给出的结果必须是正确的）。
另外，业务用例的分解也可以帮助大家理性地思考业务问题，避免人为“创造”技术挑战，业务用例的分解示例如图3-11所示。很多原来看起来属于“故障预测”的业务需求，也许用“故障在线检测”就可以满足，但两者在技术难度上的差别可能很大。例如，风力发电机的结冰预测需要微尺度的天气预报，还需要叶片表面光洁度等信息（否则解释不了平原风场的3台相邻类似风机只有1台结冰而另外2台没有结冰的现象），这样的分析问题堪称世界难题。但风场运维需要在风机严重结冰前采取适当措施，避免在高载荷下的运行对风机造成损害。及时对结冰进行检测和报警也可以满足业务需求。另外，即使能够精准预测结冰事件，在现实中也只有等到中度结冰后才会采取行动。因此，从实操性的角度来看，结冰预测没有太大价值。
图3-11 业务用例的分解示例
4. 分析问题的规约
大数据分析和应用是实现大数据价值的主要技术手段。根据技术手段，可以将大数据分析问题归为4类，如表3-7所示，不同问题的应用前提和需要解决的挑战不同。
表3-7 数据分析问题
统计类和专家知识自动化类问题对工业大数据平台提出了许多要求，包括多类型数据的有机融合、以设备或工艺为中心的全维数据查询引擎、非侵入式数据分析并行化引擎等。业务人员给出的业务逻辑通常不一致、不精准，需要利用大数据将其精细化。例如，“存在2Hz的主振动分量”的业务逻辑已经非常明确，但在进行自动化时，要细化“2Hz”的区间范围和“主分量”的研判阈值（占总能量的15%以上还是比第2高分量高5倍？）。
大数据情形下的运筹优化和经典调度在技术挑战上没有本质区别，关键是定义一个合适的范围。有许多业务因素缺乏数据支撑，还有许多业务逻辑用数学规划语言描述太复杂（可以用规则描述）、约束松弛逻辑复杂，在实际中常采用“规则+数据规划”的方式求解。大数据为运筹优化提供了更多基础数据（如成本结构、天气信息、道路交通流量等）和预测性信息（如需求预测等），与数据挖掘类问题一致。
应该充分认识数据分析的迭代性。早期对场景、因素的认识很难完备，实际数据与假设是否相符有待验证。这些不确定性都会传递到后续阶段，只有经过多次迭代才能形成相对完备的理解。
数据理解的目标是确认当前数据是否足以支撑数据分析，主要任务包括数据质量审查、数据分布探索等，目的是形成对数据的初步洞察和直觉判断。下面对工业大数据分析中的4个特别之处进行讨论。
1. 数据源的物理化：以认真负责的态度审视数据质量
在工业领域，一种常见的数据类型是传感器监测或检测数据，除了数据质量，还要考虑传感器的可靠性和安装方式，分析传感器的评价重复性和再现性（Gauge Repeatability and Reproducibility，GR&R）。在风电领域，测风仪测的风速值是尾流风速，不是轮毂风速。另外，测风仪的安装位置本身也可能存在偏差，甚至出现结冰。在化工领域，气体产量不仅要关注其流量（体积），还要关注对应的气压和温度，否则可能被“虚假表征”误导。在工程机械车联网分析中，施工动态性（如传统油位传感器数据噪声太大等）、施工环境（如数据在传输过程中丢失等）、人为破坏、部件更换、传感器及解析程序的升级换代等多种外部因素的共同作用造成数据质量审查非常复杂，有些存量数据的质量问题甚至无法解释（例如，月开工时长超过744小时）。但这些艰苦且基础的数据理解工作必不可少，否则很难保证数据分析结果的可信度。
在实践中，可以采用经典的统计方法发现数值异常，并不断深入理解哪些“异常”是系统的动力学特性（如炉温是一个大惯性、高时滞过程等）、哪些是控制逻辑行为（如磨煤机出口温度的闭环控制等）、哪些是测量系统问题、哪些是外部干扰等。只有把数据吃透，才能为后面的算法模型奠定良好的基础。
2. 数据序列的业务化：通过数据还原典型过程，发现隐性质量问题
具有挑战性的是，很多数据质量问题不能用常规手段发现，有的甚至连业务人员也意识不到。在实践中，可以利用数据还原典型过程，寻找数据中的“异常”场景，完善对业务上下文的理解。例如，气化炉炉内温度软测量的一个前提假设是CH 4 的浓度相对稳定且与炉内温度密切相关。但在实际数据探索中发现其中一台气化炉并不满足这样的假设，数据表明，CH 4 的浓度逐年上升（直到大修），基于工艺猜想这种情况是由炉子内壁不断扩大造成的，过去谁也没有意识到这样的现象。
运营和运作数据也有类似问题。例如，备件销量大不一定反映真实的市场需求，可能是代理商囤货（冲业绩）。只有把影响数据质量的主要因素考虑全面，才可能做出有意义的分析。
3. 数据量的困境：“大数据”量下的“小数据”信息
对于工业分析问题来说，即使只做简单的独立性分析，由于相关因子通常有成百上千个，若严格按照全组合进行覆盖，数据需求量将远远超过现实中可以采集的数据量。假设有20个变量，每个变量有4个取值，全组合意味着需要4 20 条数据（约1000亿条），即使采集频率达到1000Hz，也需要近35年的数据。另外，工业过程通常是一个运行在精心设计规律下的稳态过程（实际生产中并没有遍历整个参数空间），这意味着大数据中隐含的信息量其实“很少”。因此，如果不融入领域认识去消减因子数量，通常无法提供“足够”的历史数据以覆盖所有组合情形。
4. 数据的成本意识：数据分析师不要太任性
虽然希望所有的重要因子数据都能被全量采集，但现实中的数据采集是有成本的，且受制于当前的技术水平（如气化炉炉内温度是很重要的状态量，但目前的热电偶等传感器由于技术限制还无法保证长期可靠的工作）和安全、环境考虑（如长输油气管道的压力传感器只能在阀室或场站部署等）。另外，在设备故障预警或检测分析中，故障案例非常稀缺，历史运维数据通常不完整。这些问题为大数据分析带来了很大挑战，但应该认识到这就是现实（也许永远都不完美），数据分析工作就是在现实的数据条件下进行的（根据数据基础修改分析问题的提法、通过其他信息补偿关键因子的缺失或限定分析模型的适用范围等），不能任性地一味要求数据。
本阶段的目标是加工建模分析所需的数据，包括数据清洗、数据变换、特征提取、特征选择等。在实际分析项目中，特征加工会占整个项目时间的40%～60%。
针对一些特定领域的问题，特征提取应充分利用已有专业知识（不要浪费时间用数据分析手段挖掘该领域早已熟知的规律）。以2009年国际PHM Data Challenge的“齿轮箱故障模式研判”题目为例，专业组冠军利用了旋转设备的典型故障模式进行特征加工，再利用数据挖掘算法进行分析，取得了很好的结果 [8] 。近年来，深度学习的发展使我们可以在一些特定类型的问题上减少分析人员的特征提取工作量，但对关键特征量的理解在工业分析中仍必不可少。
机器学习（或统计学习、数据挖掘）分析理论趋于成熟，有明确的指导原则和丰富的算法工具。因此，在实际分析项目中，建模需要的时间反而不多，这里不再赘述。为了保证模型的可消费性（Consumability），下面介绍3点“形而上”的原则。
结果要有“新意”：避免挖掘常识，应该将常识作为前处理或特征量融入数据分析模型。
模型应遵循“极简”原则：用最简单的算法解决问题，不要为了提高微不足道的性能指标而使用看起来“高大上”的复杂模型。要抓住问题的主要矛盾，包括删失值（Censored Data）问题、样本不均衡、模型的鲁棒性（应对个别极端异常数据）、过拟合（样本量相对模型参数空间不足）、模型的自适应性和提前性（如针对宏观市场的变化，要求提前预估或事后及时适应跟踪等）、模型追求的指标（如回归问题追求的是平均精度还是最差底线，以及分类问题对漏报、误报的权衡等）、模型的可解释性（根因分析，识别哪些因素在什么情形下对工艺改进来说实操性更强）。
模型的可控性和可解释性：任何模型都是在一定前提假设下对物理世界的简化，在建模时不仅要关心平均性能，还要关心“Worst-Case（最坏情形）”，最好能够清晰给出模型的不适用场景和对应的处理措施，并解释清楚模型性能增强的原因。
如前所述，数据分析是一个迭代过程。很多模型的性能瓶颈并非来自算法本身，而是来自业务定义、数据理解和数据准备。例如，没有考虑到一些很少发生但很重要的业务或生产场景，一些重要因素没有包含在当前数据集中，没有意识到一些严重的数据质量问题等。由于工业大数据分析技能二分化，数据分析人员无法独立穷尽对业务的描述和对数据集范围之外的情形的列举，而业务专家也不可能思虑万全。例如，在一个与国际客户合作实施的地下管道失效风险评估项目中，通过业务专家访谈和领域调研拿到了相对完备的数据集。第一期模型的总体性能还不错，但发现模型在几个区域的表现并不好。当把这些区域以GIS的形式可视化到业务专家面前时，他们很快意识到一个重要因子的缺失（这些区域属于围海造田区，围海造田区的不均匀沉降比其他区域严重得多，但当前数据集没有体现这一现象），这些信息是一个非本地人士或非专业人士几乎不可能想象到的。因此，在建模过程中，不能泛泛而谈模型的性能或数据质量，应该采用“Worst-Case”驱动的方式与业务专家交流，告诉业务专家在什么情形下分析模型工作不好（给出具体例子），触发业务专家的思考，借助业务专家的外脑发现问题的根本原因，找出解决办法。
模型建立阶段已经从数据和技术的角度对分析模型进行了充分的检验，模型评价阶段从业务的角度审视模型的业务可用性（Actionable），特别要定义模型的不适用场景，并了解模型与业务流程的融合方式（Consumable）。企业生产与管理是以工艺流程或业务流程为驱动的活动，经典信息化大多根据流程进行数据采集、整合和流转，以提高业务效率，数据驱动的大数据方法尝试从数据产生、消费过程和多维度关联的新视角审视其业务价值。但如果数据分析结果不能落实到企业流程中（现有的或新创建的），分析模型就会游离在企业现有运作系统之外，很难实现价值落地。
如果采用已有的成熟模型，则本阶段尤为重要。任何模型都有一定的适用前提，有些在对外宣传时会被主动忽略，有些在模型开发时没有被意识到。因此，需要对模型是否适用于当前场景进行严谨的测试和验证。
部署模型的目的是保证模型的结果可以被业务持久、自动地消费，除了大数据平台的计算性能，还应该分析模型的全生命周期管理，因为在工业应用中，材料、工艺、装备、传感技术不断更新。应该尽可能地对部署的模型进行密切的性能监控，通过闭环反馈进行模型成熟度评估和状态管理（试用、正式应用、需更新、退役等），保证生产的可持续性和可靠性。