规则引擎

        规则引擎本质上是物联网事件和需要与这些事件相关联的动作之间的映射。在物联网环境中，事件通常使用传感器生成，所需的动作由执行器采取。本书中用于该图案的符号如下图所示：

图3.6–“规则引擎”模式的符号

        一个有趣的类比是将规则引擎与人类大脑进行比较，其中五官的使用可以比作传感器的激活，然后身体部位（例如手或腿）采取相应的动作，如下图所示：

图3.7-规则引擎解耦传感器和执行器及其与人体/精神的比较

        此外，物联网环境中的因果关系是动态的，也是复杂的，只有具备规则引擎等实体才能实现这一点。以下示例说明了这一点： 在工业环境中，当安装的摄像机检测到组装不正确的零件（事件）时，可能需要蜂鸣器发出声音。

        然而，最终，除了（或代替）简单地鸣响蜂鸣器外，要求可能会改变，在装配线上加入闪光灯并提醒工厂主管。 目前，一个家庭自动化系统被设置为在家外检测到黑暗时关闭百叶窗并打开灯。然而，一段时间后，用户可能只想打开灯，让百叶窗保持原样。 在医疗保健领域，数字健康平台可能只支持磅秤和血糖仪。然而，随着技术的进步，可能需要插入除颤器或心电图等非传统设备。随着新设备进入数字平台，拥有规则引擎将允许轻松配置规则。 传感器、执行器和规则引擎之间的信息流通常由复杂的关系组成。

        例如，规则引擎的输出可以是特定的推荐。基于这些建议，规则引擎可以自动或半自动地启动进一步的操作（取决于是否需要人工方的同意，如非人道的循环场景）。如下图所示：

图3.8–规则引擎的典型实现将涉及循环和复杂的交互

        从部署的角度来看，规则引擎可以部署在两个级别，即本地规则引擎（LRE）部署或全局规则引擎（GRE）部署。LRE部署（也称为边缘部署）有助于快速做出本地决策，在延迟或连接不完全可靠的情况下尤其有用。LRE也可以被视为GRE的数据馈送器。 GRE通常需要更高的计算能力，因此需要执行高级分析的能力。

        此外，由于多个LRE输入到一个GRE中，与LRE相比，GRE可以在更广泛、更高或更全球化的环境中运行。通常，LRE托管在设备本身或网关上。GRE可以托管在公共或私人数据中心或云端。GRE和LRE之间的关系如下图所示：

图3.9-规则引擎的实现将涉及循环和复杂的交互

        规则引擎需要在边缘设备本地或中央服务器/全局上实现，具体取决于延迟因素、数据量要求和边缘设备的当前功率/电池水平等因素。这些规则的配置可以通过中央服务器或全局接口完成，也可以通过边缘或本地接口完成（例如，如果边缘或现场设备支持人机接口（HMI或规则配置）。         规则引擎的核心可以描述为以下编程结构： 如果（（传感器1比较1阈值1）加入条件1（传感器2比较2阈值2）。。。然后 将Acuatator1状态设置为X ... 如果结束 我们可以将前面的泛型构造调整为更具体的示例。

        在家庭自动化环境中，它可能包括以下内容： 如果（（恒温器1.CurrentValue>20）和（窗口1.CurrentState=关闭）），则 空调。CurrentState=ON 空调。所需温度=20 EndIf 从前面的例子中可以推断，事件可以与操作以及建议相关联。从一个角度来看，规则引擎有助于解耦传感器和执行器，与众所周知的发布者/订阅者代理模式非常相似 提供建议而不是直接启动行动，在人在环的情况下尤其重要，在这种情况下，希望一个人做出最终决定，因为行动的影响可能会高得多——例如，在涉及其他人的安全和福祉的情况下，如在医疗保健领域。在严重疾病的情况下，规则引擎提供建议是值得的，这些建议可以由医学专家进行审查，医学专家有权决定使用的药物类型和所需剂量。可以使用诸如桌面或移动接口或智能扬声器（其是致动器的一种形式）之类的接口来提供建议。

        规则引擎可以参考历史数据来做出决策，也可以是完全无状态的——这取决于用例场景，更重要的是，取决于先前的经验是否对最终决策有任何影响。任何非琐碎的决策过程都需要将AI/ML模型集成到规则引擎中。任何不能基于simpleif X，那么do Ylogic做出的决策都可以被视为非平凡决策的一个例子。在监测过去的决策是否存在任何无意偏差的情况下，可以进一步完善AI/ML。 未来的规则引擎将充当值得信赖的顾问，他们不仅提供有意义的答案，还可以扭转问题，从而提供更具吸引力和意义的对话。另一个相关的例子可能是这样一种场景，其中规则引擎结果被策划为将用户的兴趣牢记在心。

        从本质上讲，规则引擎的建议不仅应该是正确和准确的，而且应该符合个人的信仰体系，被认为是相关的，更有可能被接受。因此，对数字个性化进行合理准确的估计起着至关重要的作用。 最后提出的建议必须根据具体程度进行调整；例如，在有针对性的答案最适合上下文的情况下，应该过滤建议以提供最小的结果（理想情况下，一个）。

        然而，如果所讨论的上下文需要广泛的一组（或范围）响应，那么该响应可以相对更通用。 与前一点相关的是，可以注意到，对特定性的需求可能不容易推断，因为它涉及到客观地估计用户的情境背景（例如文化和背景）。

        显然，情境本身就是一件复杂的事情，因为它取决于一系列不同的非确定性因素。一个相对容易（且非常有效）的因素是从为其制定建议的人那里获得即时反馈，并将这些反馈反馈到规则引擎中，从而不断提高其有效性。这导致了一个有趣的范式，即规则引擎输出的消费者和规则引擎本身不断切换角色，反过来，为提供越来越个性化和相关的建议的过程提供可信度和成熟度。 优化但相关的搜索结果集的可用性直接影响最终用户体验。

        因此，规则引擎将从仅仅是文本模式匹配机发展成为提供最相关建议的聪明、知识渊博的专家。 总之，执行智能过滤（基于个人的情绪状态和整体情境）将大大有助于设计下一代规则引擎，而不是无意识地吐出结果。希望在将结果呈现给用户之前智能地按摩和过滤结果。让我们在下一节中查看模式摘要。

模式摘要

规则引擎的模式摘要如下：

解决的问题：

商业

        根据需要灵活添加或更新规则 能够为中央服务器上的现场设备配置规则并将其推送到现场设备 能够将规则定义为数学和/或逻辑表达式以便于理解，因此允许非技术用户修改规则 允许在不同领域和/或物联网用例中使用规则（需要修改） 能够集成更先进的技术，如用于规则评估的AI/ML 技术的 传感器和致动器的抽象层的存在最大限度地减少了新传感器和致动器集成所涉及的工作量，因为代码更改仅限于抽象层。

用法上下文：

        它用于预期事件或动作的行为单独或相对于彼此发生变化的情况。 规则引擎主要通过两种方式进行部署： 完全自动化：规则引擎可以独立地做出决策并执行这些决策。这通常需要AI/ML集成。 半自动化（人工参与）：在这里，规则引擎的职责仅限于分析输入数据，然后向用户提供建议，用户最终决定要采取的行动。生成的推荐可以在用户的移动设备上以推送通知的形式发送，以便及时采取行动。 根据规则的复杂性以及现场设备的计算和存储能力，规则引擎可以在边缘或中央服务器中实现。另一个考虑因素是，在做出决定之前，需要聚合来自分布在广阔地理区域的现场设备的数据，在这种情况下，还需要在中央服务器上执行。 在需要从一组可用规则中选择特定规则的情况下。 通常，规则引擎将在DG上实现，DG充当物联网传感器和执行器之间的媒介。 示例使用场景： 在中央服务器和/或DG处托管或部署，用于以结构化方式配置或执行规则 解耦物联网事件和相关的动作和命令，允许扩展以适应未来的事件、动作和命令 模式原理： 提供一种结构化机制，用于解耦现场设备和/或中央服务器上的事件和操作，消除了需要添加自定义管道逻辑以适应每个新事件和/或操作的需要，从而提高了系统的可维护性 有助于将复杂事件转换为数学/逻辑表达式，以便于理解和修改 通过集成AI/ML技术，提供选择要应用的特定或最佳规则（从一组潜在规则中）的能力 相关模式： 没有一个 假设： 数据在被馈送到规则引擎之前被预处理和/或归一化（输入侧数据按摩）。类似地，数据被转换成致动器所需的形式（输出侧数据按摩）。 规则引擎将能够维护状态信息，并在期望人员对建议的操作提供最终授权的情况下等待状态更改。 中央服务器和现场设备之间需要时间同步，尤其是在评估将时间定义为参数之一的情况下。 注意事项： 规则将基于以下因素部署在设备网关（现场设备）或中央服务器上： 现场设备的计算能力与中央服务器的计算能力相对于执行规则的计算需求（计算或存储或两者兼有）。 获取规则引擎结果所需的时间。重要的是要理解，除了在中央服务器执行规则所需的时间外，还需要根据以下等式考虑数据传输过程中引入的延迟： 总计=TDS（设备网关和中央服务器之间的数据传输时间） + TR（实际规则评估时间） + TSD（从中央服务器开始并返回现场设备的数据（规则结果）传输时间） 根据除了规则执行之外是否需要规则选择，需要在设备网关或中央服务器调用合适的AI/ML模型。 规则引擎可以集成所评估规则的日志记录，以提供审计跟踪并用于故障排除。 反模式场景： 传感器/执行器列表相对静态的用例 事件和操作之间的关系是简单的和/或静态的，并且可以在总体逻辑中进行硬编码的用例。