📚 课程目录第3章规则引擎核心组件

3、规则引擎核心组件：事实（Fact）、规则（Rule）、动作（Action）、工作内存（Working Memory）

在FMS报警规则引擎中，事实（Fact）、规则（Rule）、动作（Action）与工作内存（Working Memory）构成了推理循环的四大支柱。理解这四者的定义、交互方式及生命周期，是配置高效、可维护报警逻辑的前提。

3.1 核心组件总览

规则引擎采用“数据驱动”的推理模式：事实被断言到工作内存中，规则引擎通过模式匹配算法（如Rete）评估规则的条件部分，当条件满足时触发对应的动作。下表总结了各组件的职责与特征：

组件	英文	核心职责	生命周期	典型示例
事实	Fact	表示系统状态、事件或数据点	由外部系统断言或撤回	温度传感器值 > 85°C
规则	Rule	定义条件（LHS）与结论（RHS）	静态加载，动态激活	IF 温度高 THEN 触发高温报警
动作	Action	规则触发后执行的具体操作	瞬时执行，可产生新事实	发送报警通知、写入历史库
工作内存	Working Memory	存储所有当前活跃事实的容器	持续存在，随事实变更	包含所有传感器最新值

关键概念： 工作内存是规则引擎的“短期记忆”，所有推理都基于工作内存中的事实快照进行。事实的插入、更新、删除操作都会触发规则重新评估。

3.2 事实（Fact）—— 系统的“脉搏”

事实是规则引擎处理的基本数据单元。在FMS场景中，事实通常对应一个设备测点的瞬时状态或事件。事实必须具备以下属性：

唯一标识：如 FAB101_CHILLER_01_TEMP，用于区分不同数据源。
时间戳：记录事实产生的时间，用于时序推理。
值域：数值、枚举或字符串，如 85.3、ALARM。
元数据：设备类型、区域、优先级等上下文信息。

事实的典型结构（JSON表示）：

{
  "factId": "TEMP_SENSOR_1023",
  "timestamp": "2025-03-21T14:30:00.000Z",
  "value": 87.5,
  "unit": "°C",
  "metadata": {
    "deviceType": "Chiller",
    "location": "Cleanroom_A",
    "priority": 1
  }
}

设计建议： 事实应尽量保持扁平化，避免深层嵌套。嵌套结构会增加规则条件编写的复杂度，并降低模式匹配效率。

3.3 规则（Rule）—— 推理的“大脑”

规则由两部分组成：条件部分（LHS，Left-Hand Side） 和 结论部分（RHS，Right-Hand Side）。条件部分定义事实必须满足的模式；结论部分定义当条件满足时要执行的动作。

规则的基本语法（伪代码）：

rule "高温报警规则"
when
    $temp : TemperatureFact(value > 85.0, unit == "°C")
then
    // 动作：创建报警事实
    AlarmFact alarm = new AlarmFact();
    alarm.setSource($temp.getFactId());
    alarm.setSeverity("HIGH");
    alarm.setMessage("温度超过85°C阈值");
    insert(alarm);  // 将新事实插入工作内存
end

规则的关键特性：

声明式：只描述“要什么”，不描述“怎么做”。
可组合：多条规则可以同时激活，引擎通过冲突解决策略决定执行顺序。
可继承：支持规则模板，通过参数化实现同类逻辑复用。

3.4 动作（Action）—— 执行的“手脚”

动作是规则引擎与外部世界交互的接口。每个动作可以执行以下操作之一：

动作类型	说明	FMS典型用途
断言事实	向工作内存插入新事实	创建报警记录、生成联动指令
更新事实	修改工作内存中已有事实	更新报警确认状态、修改优先级
撤回事实	从工作内存中移除事实	消除已恢复的报警
调用外部服务	执行Java方法、REST调用、数据库操作	发送邮件、写入历史库、控制PLC
日志记录	输出调试或审计信息	记录规则触发轨迹

注意： 动作中应避免执行长时间阻塞操作（如同步HTTP调用），否则会阻塞规则引擎的推理循环。建议将耗时操作放入异步队列处理。

3.5 工作内存（Working Memory）—— 推理的“舞台”

工作内存是规则引擎的核心运行时数据结构。它维护了一个事实的集合，并支持高效的模式匹配。工作内存的主要操作包括：

insert(Fact)：将新事实加入工作内存，触发规则评估。
update(Fact)：修改已有事实，重新评估受影响规则。
delete(Fact)：移除事实，撤销相关规则激活。

工作内存的内部机制：

事实索引：引擎为事实建立索引（如哈希索引、树索引），加速条件匹配。
冲突集：存储所有满足条件的规则实例，按优先级排序。
议程（Agenda）：管理冲突集的执行顺序，支持优先级、显式顺序等策略。

3.6 组件交互流程（SVG图）

下图展示了从事实断言到动作执行的完整推理链路：

3.7 组件间的数据流与状态变更

规则引擎的推理循环遵循“匹配-解决-执行”三步迭代：

匹配阶段：引擎将工作内存中的事实与规则库中的条件进行模式匹配，生成激活的规则实例。
解决阶段：引擎根据冲突解决策略（如优先级、最近使用、显式顺序）从冲突集中选择一条规则执行。
执行阶段：执行选中规则的结论部分（动作），动作可能修改工作内存，触发新一轮匹配。

这种循环持续进行，直到没有新的规则被激活（达到固定点）。

性能要点： 工作内存的大小直接影响匹配效率。在FMS系统中，建议将工作内存中的事实数量控制在10万以内，并通过事实的时效性（TTL）自动清理过期数据。

3.8 组件配置示例（FMS场景）

以下是一个完整的规则引擎配置片段，展示了四个组件如何协同工作：

// 1. 定义事实类型
declare TemperatureFact
    factId : String
    value : double
    unit : String
    timestamp : long
end

declare AlarmFact
    sourceId : String
    severity : String
    message : String
    timestamp : long
end

// 2. 定义规则
rule "冷却水温度高联动"
    salience 10  // 优先级
    when
        $temp : TemperatureFact(value > 80.0, unit == "°C")
        not(AlarmFact(sourceId == $temp.factId, severity == "HIGH"))
    then
        AlarmFact alarm = new AlarmFact();
        alarm.setSourceId($temp.factId);
        alarm.setSeverity("HIGH");
        alarm.setMessage("冷却水温度超过80°C，建议启动备用冷却塔");
        alarm.setTimestamp(System.currentTimeMillis());
        insert(alarm);  // 动作：断言新事实到工作内存
        
        // 调用外部服务
        System.out.println("触发联动：启动备用冷却塔");
end

// 3. 外部系统断言事实
workingMemory.insert(new TemperatureFact("CT_01_TEMP", 82.5, "°C", ...));

最佳实践： 在规则条件中使用 not() 可以避免重复报警。只有当工作内存中不存在相同来源的未恢复报警时，规则才会触发。

通过以上四个组件的紧密配合，FMS报警规则引擎能够实现从数据采集、逻辑推理到动作执行的完整闭环，为厂务监控系统提供实时、准确的报警与联动控制能力。