在工业日常运作中存在大量经验知识，在这些知识中，只有少部分以经验公式、操作规程等方式沉淀下来，大部分仍然隐性地存在相关人员的头脑中，以传统的师徒传授方式传承，传承的不确定性和效率都有较大的提升空间。除了数据驱动的机器学习工程方法，还有专家规则开发的工程方法，这种工程方法将隐性研判逻辑显性化、形式化、定量化，形成切实可行的经验模型，加快知识的传播与传递，整体拉平大家的认识水平（并让知识变得可积累、易传承）。将烦琐、频发但明确的逻辑自动化，能够将部分业务人员从低价值劳动中解放出来。

经验知识有3种常见的表达形式：①专家规则，通过访谈等活动以规则研判的形式刻画专家经验；②经验公式，如轧制过程的古布金宽展公式、油层破裂压力经验公式等；③案例库，将过去发生的事件及其过程上下文保存下来，通过文本挖掘等手段，实现类似案例的灵活检索。经验公式在检验和应用中与机器学习类似，这里不重点讨论。在第4章中结合故障诊断讨论案例库。本节集中讨论住专家规则。

提到专家规则，大家自然会想到业务规则管理系统（Business Rule Management System，BRMS）和复杂事件处理引擎（Complex Event Processing，CEP）。BRMS在产品报价、工单审核、合规性检查等方面有广泛应用，能够将业务逻辑从应用逻辑中剥离，提高应用对业务变化的响应速度。CEP在流数据处理中有广泛应用，典型特点是条件语句有时间窗。下面讨论一种专家规则的表达方式：规则分类，指出工业场景中经验模式多为事件规则，并讨论专家规则的开发流程。

3.3.1 业务规则的技术和方法

1. 规则分类

Boyer和Mili ^[9] 从业务语义的角度，对业务规则进行了分类，业务规则的元模型（Meta Model）如图3-12所示。OMG（Object Management Group）在SBVR（Semantics of Business Vocabulary and Business Rules）和BMM（Business Motivation Model）标准 ^[10] 中，对业务策略（Business Policy）和业务规则（Business Rule）的概念做了辨析，它们都属于业务指令（Business Directive），但业务规则是可被执行的形式化业务指令，业务策略是语言描述的指导原则，通常为非结构化文档资料，不能直接执行。

业务规则包括结构性规则（Structural Rule）和操作性规则（Operational Rule）。结构性规则描述不同业务短语及其组成关系，通常用来定义业务对象（Business Object）。操作性规则分为7类（参考了文献[11]中的分类），如表3-8所示。

2. 业务规则开发方法论

存在很多类似的业务规则开发方法论。ABRD（Agile Business Rule Development）方法论 ^[9] 将业务规则开发分为发现（Discovery）、分析（Analysis）、设计（Design）、审批（Authoring）、验证（Validation）、部署（Deployment）6个阶段，如图3-13所示。Ross ^[12] 将其划分为范围定义（Scoping）、发现（Discovery）、分析（Analysis）、设计（Design）、实施（Implementation）、测试（Test）6个阶段。

这些阶段划分与一般的IT应用开发类似，不同的是每个阶段的工作内容、方法和评价原则。例如，在分析（Analysis）阶段，Halle ^[11] 给出了规则质量的10个度量指标，包括根据单条规则是否契合（Relevant and justified）、原子性（Atomic）、声明式（Declarative，相对于Imperative）、完整（Complete）、可靠（Reliable）、可信（Authentic）而提出的7条度量指标，以及规则集（Rule Set）的Completeness（完备性），Uniqueness、Nonredundancy、Minimality（唯一性、非冗余、极简），Consistency（一致性）3条准则。在设计阶段，Halle ^[11] 提出了业务规则的STEP（Separating，Tracing，Externalizing，Positioning）目标原则，即将规则从应用系统剥离（Separating）以便重用，规则可跟踪（Tracing）能够更好地评估其影响，将规则显式化（Externalizing）能够使更多人了解并审视其影响，将规则管理系统化（Positioning）可以更敏捷地响应业务需求。

上述步骤实现了经验知识从业务理念到自然语言，再到形式规则语言，最终到规则引擎语言的逐渐清晰的过程，这与业务规则识别方法论的目标和思路基本一致，区别在建模对象和业务逻辑方面。

3.3.2 工业专家规则的特点

工业专家规则与业务规则在目标和动机、规则来源、规则表达、对IT技术的期望方面有很大区别。工业专家规则与业务规则的应用场景区别如表3-9所示。

以透平设备故障诊断为例，工业专家规则有两种常见形式。

（1）If-Then规则，通常根据状态数据进行故障类型预判。如果（If）在稳态运行过程中，轴承4个测点的振幅均出现跃变，前轴承振动的频谱无变化，后轴承振动的工频振幅明显增大，则（Then）故障类型为“转子上的零部件脱落”。

（2）规则研判Flow形式示例如图3-14所示，通常用来进行事后的故障排查（如类型研判、故障原因定位等），中间也掺杂一些Computation规则（如确定振动发生的临界转速）。

以上两种工业专家规则具有以下特点：①条件语句中都有显式的时间窗概念（与ECA类型的规则类似），这对规则表达和规则引擎都提出了新要求。更复杂的是，工业专家规则的时间窗除了显式表达（如最近5分钟等），还有很多隐式表达（如在稳定运行期间等）；②在建模元语上，工业专家规则需要很多时序模式（如“无变化”“缓慢上升”等）的研判；③在规则间的逻辑冲突上，工业专家规则通常允许部分“冲突”（如同时报告多种故障类型等），但业务规则通常需要提前消除可能的逻辑冲突；④在执行方式上，业务规则通常采用Rule Set，采用Rete等算法执行，而工业专家规则常常采用混合模式：在大层面上采用Flow，局部采用Rule Set模型。工业专家规则与业务规则的建模技术区别如表3-10所示。

基于讨论，得到工业专家规则的开发方法需要突出以下几点。

（1）在规则的开发过程中，工业专家规则通常采用“Bottom-Up”方式，如何保证全面性？归纳总结的规则逻辑很难完备，需要在应用中反复迭代。

（2）在规则的分析中，如何在强机理背景下，保证每条规则的原子性？

（3）在规则的形式化中，归纳规则描述元语非常重要。

3.3.3 专家规则开发的AI-FIT-PM方法论

考虑工业应用的特色，参考工业中故障诊断知识库的开发流程 ^[13] ，我们提出了具有5类角色、7个阶段的快速迭代开发模式，专家规则开发的AI-FIT-PM方法论如图3-15所示。在前几个阶段，主要考虑专家规则采用“Bottom-Up”方式时工作内容的细化；在需求分析阶段，引入工业参考框架以保证问题分解的全面性；在知识获取和知识形式化表达阶段，归纳业务元语。

1. 需求分析阶段

基于业务的分解模型，梳理专家规则的规划蓝图（Blueprint），并结合技术可行性和重要性确定优先级，形成可落地的路线图（Roadmap）。例如，水力发电机组故障诊断要基于故障树分析（Fault Tree Analysis），并结合故障的发生频率和影响评估，确定故障诊断的方向，指导诊断规则的构建，故障树分析示例如图3-16所示 ^[14] 。

2. 知识获取阶段

根据系统结构与工作原理梳理定性的领域知识。该步骤一般由领域专家提前完成，也可以由知识工程师通过业务访谈、文献调研完成，知识获取过程如图3-17所示。

知识获取的重要基础是理解系统的运行机制和失效过程、了解监测机制、梳理研判逻辑。

（1）理解系统的运行机制和失效过程：知识工程师应该对运行机制或失效过程有形式化理解，并根据关键过程量间的关系构建定性的系统动力学（System Dynamics）模型，磨煤机的系统动力学模型示例如图3-18所示 ^[15] 。为避免陷入细节，这里不需要常微分方程、偏微分方程等数学公式表达的动力学方程，而是需要一个经过抽象（忽略次要因素）且能够清晰反映变量间影响关系的概念模型（Conceptual Model）。

（2）了解监测机制：知识工程师要了解监测点位、测量原理等信息。很多数据异常都由传感器引起。

（3）梳理研判逻辑：在动力学根因分析的基础上，参考行业标准，确定研判逻辑的完备性。

3. 知识形式化表达阶段

将领域知识转化为形式化业务规则，进一步消除歧义。该阶段包含两个步骤。

（1）规则流图描述：用相对严格的规则流图对上面总结的定性运行经验进行刻画，并补充一些隐性的前提条件，规则流图如图3-19所示。该步骤通常由知识工程师主导完成，可能需要与领域专家进行2～3轮的确认与更新。

（2）总结归纳故障描述元语：对于一个非全新的规则诊断定义问题来说（业务对象模型和特征算子、征兆算子已经定义或开发好了，特征算子与征兆算子如表3-11所示），知识工程师应该用既有的故障描述元语和业务对象模型进一步形式化（可以将当前没有得到支持的算子及时反馈给算法工程师）。

对于一个全新的领域来说，该步骤需要知识工程师与算法工程师（甚至业务数据建模工程师）协同工作才能完成。

4. 其他阶段

算法的研发与测试可以遵循CRISP-DM等方法论和规范。知识工程师利用算子、业务对象模型进行形式化建模，并在样例数据上确定研判阈值并进行逻辑验证。可以借助大数据并行化分析引擎，采用测试驱动的模型开发模式（Test Driven Model Development）实现快速迭代验证。对于缺少的算子和依赖历史数据的超参数设置、逻辑验证过程，可能需要算法工程师的配合。如果在样例数据上发现逻辑缺陷或反例，可能需要对前述步骤进行多次迭代。

正常业务模型的入库管理、配置（与机组的关联、运行周期设置等）需要在日常运维阶段定期对规则的精度和适用性进行审查（如果具备数据条件，则应该事先进行自动评价）。对于性能下降的情况，应及时启动再开发甚至下架流程。

3.3.4 专家规则模型对软件平台的需求

在应用专家规则时，常常会遇到如表3-12所示的7大挑战，这些挑战对软件平台提出了相应的要求。作为重要的数据提供软件，大数据平台要求能够支撑规则的快速迭代和开发。