物联网应用程序设计与典型的IT解决方案大不相同，因为它将物理操作技术（OT）与传感器、致动器和通信设备连接起来，并将数字信息技术（IT）与数据、分析和工作流连接起来。
在企业环境中，物联网非常复杂，这不仅是因为大型企业的物联网部署几乎肯定需要快速扩展到数千台，然后数十万台设备（或传感器）或更多，但也因为该解决方案需要跨所有其他企业系统工作，并符合特定的企业软件要求。
这两个世界之间的桥梁对于如何在物联网应用程序中构建业务逻辑和业务规则具有重要而独特的影响。可用于物联网领域的不同规则引擎技术。术语“规则引擎”的使用非常松散，泛指自动化技术，而不仅仅是典型的业务规则引擎。
基准标准
特定技术
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
具体实施情况
. 解释能力
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●设计期间和运行时的模拟和调试能力
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
基准中评估的规则引擎
. 基于前向链接算法的规则引擎。目前市场上的大多数物联网平台都有这类规则引擎：Redhat Drools、Cumulocity、Eclipse智能家居、AWS规则引擎、Thingsboard等。
. 支持if/then或if/then/else模式的条件/操作规则引擎。即使它们只使用一个条件语句，它们也可以被视为前向链接类别，但我们将分别对它们进行评估，因为FC引擎的大多数分数并不适用于它们。这组引擎的一个流行例子是物联网数字服务ifttt.com网站。
. 基于流式编程（FBP）的规则引擎是由J.paulmorrison在上世纪年代在IBM发明的，其中最著名的例子就是Yahoo！管道和节点红色。大多数SaaS自动化规则引擎都是这种类型的。并附带说明了节点红色与一般FBP类别的区别。
. 流处理规则引擎在数据产生或接收时直接处理动态数据。例如Apache Storm、Flink、Samza等。
. 复杂事件处理（CEP）引擎是流处理引擎的前身，在处理事件的方式上与它们不同。它们大多部署在边缘计算中，例如WSO、Litmus或Foghorn。
. 有限状态机（FSM）。状态是对等待执行转换的系统状态的描述。转换是在满足条件或接收到事件时要执行的一组操作。业务规则引擎（BRE）是FSM的一个例子，它允许非程序员更改业务流程管理（BPM）系统中的业务逻辑。另一个例子是AWS Step函数，它将工作流转换为状态机图。Salesforce的IoT Explorer也是一个基于FSM的规则引擎。
.决策树（Decision tables）是一种简明的可视化表示，用于根据给定的条件指定要执行的操作。它们是算法，其输出是一组动作。决策表中表达的信息也可以表示为决策树，或者在编程语言中表示为一系列if-then-else和switch-case语句。
. Waylay规则引擎*是一个推理引擎，它建立在一个独特的视角上，结合了两个关键的人工智能概念-贝叶斯网络和智能代理概念。（“用于建模、实例化和/或执行应用程序中的贝叶斯代理）。
前链发动机
使用前向链接（FC）的推理机应用一组规则和事实来推断结论，搜索规则直到找到IF子句为真的规则为止。将新的或现有的事实与规则进行匹配的过程称为模式匹配，FC推理机通过各种算法（如Linear、Rete、Treat、Leaps等）进行匹配。
当发现某个条件为TRUE时，引擎执行THEN子句，从而将新信息添加到其数据集中。换句话说，引擎从许多事实开始，并应用规则从这些事实中得出所有可能的结论。这就是“前向链接”这个名称的由来——事实上，推理机从数据开始，并将其向前推到答案，而反向链接则相反。
倒链侧注
在后向链接中，系统从结论到事实反向工作，这种方法称为目标驱动。与前向链接相比，请求的数据很少，但搜索的规则很多。在这个基准测试中，我们有意识地选择不考虑反向链接规则，因为它们不适合动态情况，而且大多只作为决策中的专家系统使用。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
在规则中组合多个非二进制函数结果（观察值）是不可能的，因为条件应用于布尔（真/假）结果。
FC引擎几乎在多数投票要求下“崩溃”，因为它们搜索推理规则，直到找到一个或多个IF子句为真的地方。这意味着多个潜在矛盾的规则可能同时触发，引擎需要处理冲突解决方案来决定执行哪一个。在这一组合中加入多数票太难处理了。
基于先前观察结果有条件地执行函数并不容易，例如FC规则引擎希望在评估规则时所有数据都存在。我们仍然给他们打满分，因为他们为表达条件（布尔）逻辑提供了一个很好的框架。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
FC引擎无法在一个规则中表达时间维度——所有通过前向链接建模的规则感觉就像它们在时间上被冻结了一样。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
FC引擎不能在规则内表达不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
●设计期间
●运行时
对于简单的问题，FC引擎为我们提供了设计规则的简单方法。事实上，没有比这类规则更容易掌握的了！然而，在规则中添加更多的条件语句会导致非常复杂的分析，这会阻碍对规则意图的理解。
此外，规则的实际条件（通常包括阈值和其他布尔表达式）被写入并隐藏在代码中的某个地方，因此很难向外部观察者公开。作为一种解决方法，在设计阶段，规则通常被表示为带有条件结果的图形，并将其标记为“箭头”。然而，一旦规则被实现，这些图形就不可能被看到或检查。
模拟、调试和决策跟踪（为什么在运行时触发规则）不是一项简单的任务，因为数据决定了选择和使用哪些规则的路径。此外，如前所述，冲突解决需要预先选择冲突解决策略，该策略不是规则的一部分，而是规则引擎的配置参数。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
更改规则是可能的，但总是有问题的，因为每次规则中的条件发生更改时，都需要重新评估冲突解决方案。
将第三方API服务添加到前向链接引擎不是一项简单的任务，它通常直接在代码中完成，从而导致API端点在规则级别直接耦合。由于阈值和其他条件也经常在代码中定义，因此很难跨多个实例化规则重用相同的API服务。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型等轻松搜索规则
过滤器
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
只要阈值和其他条件不随设备的变化，就可以在多个设备上应用相同的规则。任何更复杂的东西都很难用FC实现，因为规则的许多输入都深深地埋藏在代码中。
. 体系结构可伸缩性（分片和分布式计算）
前向链接规则是无状态的，这意味着您可以轻松地并行运行多个规则，但不能在执行一个规则实例时将负载分配给不同的进程。
条件作用发动机
尽管我们可以认为基于条件-动作（CA）的规则引擎属于前向链接引擎组，但我们决定将它们作为一个单独的类别进行评估，因为许多通用的FC注释并不适用于它们。原因是条件操作规则引擎不允许多个条件，这一方面使它们的逻辑表达式能力非常有限，另一方面，可伸缩性更高。条件操作规则引擎（if this-then that）有时会用ELSE语句（if this-then-ELSE-that）进行扩展。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
与FC引擎不同，CA引擎不能建模任何复杂的逻辑（组合多个非二进制结果、多数投票、条件执行）。它们用于非常简单的用例。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
这些引擎解决时间维度问题的一个方法是，它们通常依赖外部触发器来确定要执行的规则。也就是说，规则的IF条件变成了WHEN条件（例如，天气不好时，发出警报；当我回家时，打开灯）。在这些工具中，这通常被称为触发器，尽管我们可能会认为这不是规则引擎本身的一部分（因为它需要在其他地方编码），但如何将时间维度引入规则引擎仍然是显而易见的。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
●CA规则引擎不能在规则中表达不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
就像前向链接引擎一样，IFTTT这样的CA引擎为我们提供了一种为简单问题设计规则的简单方法。没有什么比这条规则更容易理解的了！
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
CA引擎既灵活又可扩展。添加第三方API服务相当简单，因为API扩展需要最少的抽象（if和act部分）。然而，由于CA引擎的性质，在规则内使用API服务存在局限性。
大多数情况下，CA引擎使用API服务作为触发动作，而不是作为输入，因为只有一个条件输入槽可用，在IoT用例中，通常由设备数据获取。例如，一个典型的例子是，如果设备温度高于此温度，则调用外部API服务（SMS、电子邮件、支持票证等）。
当CA引擎将API服务的数据建模为输入时，那么我们不能将此API服务输入与设备数据相结合，因为使用了单个输入插槽，因此我们只能将该设备用作执行器（例如“打开灯”）。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
只要阈值和所有其他条件不变，就可以在许多设备上应用相同的规则。使用这样的规则引擎，模板化、版本控制和可搜索性相当容易实现，但批量升级更困难，因为条件和阈值通常是全局变量，很难根据运行规则的每个实例进行更改。
. 体系结构可伸缩性（分片和分布式计算）
CA规则是无状态的，非常简单，所以很容易扩展这些规则引擎。然而，它们并没有得到这个类别的最大分数，因为可伸缩性实际上只通过一个规则引擎类别来实现，即流处理引擎。
流处理引擎
基于流的编程（FBP）是一种编程范式，它将应用程序定义为“黑盒”进程的网络。这些过程，a.ka。函数表示为通过消息传递跨预定义连接交换数据的节点。这些节点可以无休止地重新连接以形成不同的应用程序，而不必改变它们的相关功能。
因此，FBP自然是“面向组件的”。FBP的一些好处是：
●在不重写部件的情况下更改连接接线。
●固有并发-适用于多核CPU世界。
雅虎！Pipes和Node RED是使用FBP范式构建的规则引擎的两个示例。随着“无服务器”计算的引入，FBP变得更加流行，在这种计算中，可以通过链接函数来构建云应用程序。
IBM的OpenWhisk是一个通过链接云函数（IBM称之为actions）的基于流的编程的例子。另一种基于有限状态机规则引擎（如AWS step函数）的无服务器编排方法将在后面讨论。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
FBP没有状态和状态转换的概念。在规则中组合函数（观察）的多个非二进制结果仍然是可能的，但必须在应用它的每个函数中进行编码。这也意味着你必须在每一个需要为多选结果建模的函数上分支。这会导致非常繁忙的流程图，很难理解，特别是因为逻辑是在函数本身和它们的“连接器”（connector）路径执行中表达的。这些连接线在某种程度上不仅暗示了信息流，而且也暗示了正在做出的决定。
与决策树（将在后面进一步讨论）类似，这种建模方法会随着逻辑复杂性的增加而出现节点数量的指数增长。更糟糕的是，与决策树不同，我们无法将函数结果作为状态来跟踪。对于这个缺点，没有比使用node RED实现的稍微复杂一点的流，并计算节点和连接器的数量更好的说明了。node RED用or节点和连接器设计的简单用例并不罕见，这些用例几乎不能放在一个屏幕上。
只有引入将不同节点的输出合并到一个单独的合并节点的概念，流引擎中的多数投票才有可能实现。即使如此，它仍然有问题，因为它需要在合并节点的函数中编写多数规则。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
流引擎几乎不能处理时间维度的任何方面，因为FBP通过设计是一个无状态规则引擎。在一些有限的用例中（很难扩展），您可以在一个时间窗口内合并流。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
FBP规则不能表达规则中的不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
对于简单的用例，基于流的数据流表示感觉很自然，至少从信息流的角度来看是这样。但是任何使用FPB创建复杂逻辑的尝试都会使验证预期逻辑变得非常困难。
尽管如此，通过查看流程图来理解哪些决策是非常困难的。其主要原因是逻辑表示不紧凑，规则的验证通常需要流式测试数据，然后在所有管道上验证函数日志。
逻辑在流路径（数据在处理节点之间传输）和每个节点中的有效负载处理之间被分割，这可能导致在处理节点之后采用不同的路径。因此，调试和规则验证成为一个非常乏味和容易出错的过程。此外，我们不确定所有的角点情况（作为来自不同输入的决策的输出）都被用FBP表示的特定规则所覆盖，这看起来就像基于FBP的规则验证是一个NP-hard问题。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
FBP引擎具有可重用的黑盒节点（函数）。然而，任何特定规则的部分更新仍然是困难和风险的，因为这通常意味着对图形的重大更改和规则的重新验证。。在某种程度上，这主要是因为对于大多数规则引擎来说
特别是FBP，可解释性和灵活性之间有很高的相关性。
基于流的规则引擎很容易用第三方服务进行扩展，并且以一种优雅的方式实现了可扩展性。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
模板化很难实现，因为在处理有效负载在不同处理节点之间传递时发生的有效负载转换时需要特别小心。此外，阈值和分支逻辑是同一有效负载处理流程的一部分，这使得抽象这种逻辑非常困难。正是因为这个原因，批量升级容易出错，而且风险很大。
. 体系结构可伸缩性（分片和分布式计算）
FBP引擎本质上是并发的，因为它们必须分布函数计算。它们也是无状态的，这意味着规则引擎只需要跟踪当前的执行和需要执行的进一步操作。另一方面，如果在一个规则中需要合并不同节点的多个输出，或者当使用不同的路径执行引入决策分支时，规则引擎将需要将规则执行的快照（范围）保留在某个地方。
流量引擎侧注：节点红色可操作性
节点RED比FBPs有更大的可操作性问题。主要原因是它的作者选择让不同的协议流作为输入数据事件直接进入节点。这是故意这样做的，以简化协议终止，并允许在节点RED中执行有效负载规范化。但这是一把双刃剑。
一方面，它意味着依赖于协议的数据流可以由任何第三方实现并在node RED环境中立即使用。这就是为什么node RED今天在maker社区非常受欢迎的原因，也是为什么它是许多工业供应商门户中事实上的工具。由于协议转换和负载规范化在物联网部署中非常重要，因此节点RED对于边缘部署非常有价值。
另一方面，同样的决定使得模板化变得更加困难：协议转换和有效负载规范化需要与阈值定义和分支一起成为节点RED模板的一部分。
体系结构可伸缩性（分片和分布式计算）
虽然很适合边缘部署，但是现成的节点RED实例对于云来说是不可伸缩的。一些供应商提供云解决方案，在节点RED上实现切分，并将协议终止外部化在一个单独的组件中。然而，当采用这种方法时，他们也可以切换回更通用的FPB引擎。
决策树/决策表
获取条件规则复杂性的一种常用方法是使用决策树，决策树是使用分支方法来说明决策的每个可能结果的图形。市场上有几种产品提供基于决策树/表的规则引擎。
Drools主要以其基于前向链接的规则引擎而闻名，它也有一个与决策表集成的扩展，它使用excel表与嵌入代码片段相结合来适应任何额外的逻辑或所需的阈值。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
当每个变量的状态数有限时（例如二进制是/否状态），决策树很有用，但当状态数增加时，决策树可能会变得压倒性。这是因为树的深度随着变量的数量线性增长，而分支的数量却在增长
与状态数成指数关系。例如，对于布尔变量，有^=^=，，，，，不同的决策树（在文献中，通常称为“决策树的假设空间”问题）。
多数投票是不可能的，除非我们进一步分支，在这里，多个不同的结果也是树结构的一部分。有条件的执行应该是现成的。顾名思义，决策树都是关于有条件执行的。尽管如此，决策树从来没有在物联网环境中实现。在专家系统中，决策是问答场景的结果，当新数据（问题）被提供给决策树引擎时，逻辑将遵循条件执行。另一方面，在物联网环境中，我们向规则引擎提供数据，并期望决策结果返回。在这种情况下，我们讨论决策表，这意味着我们将数据输入决策表，结果（决策）立即返回。我们仍然给决策树打满分，因为可解释性使决策树在这种能力非常重要的用例中非常有吸引力（例如医疗保健等）。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
我们不能用决策树来建模时间维度，除非我们将时间信息作为节点包含在树中（例如周末、星期几、一天中的时间等）。即便如此，我们也不能用时间来表达我们潜在观察结果的变化，因此这些都是不可能的：处理过去（处理过期或即将过期的信息）、处理现在（结合异步和同步信息）、处理未来（预测和异常检测）。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
决策树使用白盒模型。重要的见解可以根据领域专家描述情况和他们对结果的偏好产生。但是决策树是不稳定的，这意味着数据的一个小的变化就可能导致最优决策树的结构发生很大的变化。它们通常也相对不准确。计算可能会变得非常复杂，特别是在许多值不确定和/或许多结果关联的情况下。决策树不能建模不确定性和效用函数，除非像时间信息一样，在树中添加这些作为决策节点，这会使决策表更加复杂。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
决策树易于理解和解释。人们只需简单的解释就可以理解决策树模型。但是，一旦规则被实例化，决策就不能被看到或检查，并且在设计阶段只在图中被标记为“箭头”。当实现为决策表时，可解释性进一步下降，因为表中的每一行都是一个规则，而该行中的每一列都是该规则的条件或操作。这会导致整个序列不清晰-决策表没有给出总体情况。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
决策树主要用于图形化知识表示。使用决策树构建规则引擎非常困难，在其上构建应用程序则更加困难。它们很难与任何第三方系统一起扩展。而且，训练数据的任何微小变化都会导致最优决策树结构的巨大变化。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
在多个设备上应用相同的决策树规则几乎是不可能的，因为大多数决策树通过将驻留在决策表中的逻辑与代码中单独定义的操作混合起来来实现规则，这使得管理整个过程变得非常困难。
. 体系结构可伸缩性（分片和分布式计算）
决策树规则是无状态的，这意味着，理论上，并行运行多个规则应该很容易。但是，在规则的一个实例中，不能在执行某个特定规则时将负载分配给不同的进程。事实上，树的深度与变量的数量成线性增长，而分支的数量则随着状态的数量呈指数增长，这使得决策树很难扩展，如果不是不可能的话。计算可能会变得非常复杂，特别是在许多值不确定和/或许多结果关联的情况下。
流处理引擎
流处理是对动态数据的处理——换句话说，在数据产生或接收时直接对其进行计算（与MapReduce数据库（如Hadoop）不同，后者在静止时处理数据）。
在流处理作为处理连续数据集的标准出现之前，这些数据流通常存储在数据库、文件系统或其他形式的大容量存储中。然后应用程序将查询存储的数据或根据需要计算数据。这种方法的一个显著缺点（广泛称为批处理）是在创建数据和使用数据进行分析或操作之间存在延迟。
在大多数流处理引擎中，用户必须编写代码来创建运算符，将它们连接到
绘制并运行它们。然后引擎并行运行图形。流处理示例
引擎有Apache Storm，Flink，Samza等。
当从数据流接收到事件时，流处理应用程序立即对该事件作出反应。应用程序可能触发一个操作，更新一个聚合，或者“记住”事件以备将来使用。
流处理计算还可以联合处理多个数据流，并且事件数据流上的每个计算可以产生其他事件数据流。
流处理引擎在IoT中的使用范围很窄-用于IoT数据流的运行时处理。它们不是作为通用规则引擎设计的，例如不能直接在设备上启动。
流处理规则引擎通常用于算法交易、市场数据分析、网络监控、监控、电子欺诈检测和预防、点击流分析和实时合规（反洗钱）等应用。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
流规则引擎不可能有高阶逻辑结构（组合多个非二进制结果、多数表决、条件执行）。然而，开发人员可以在数据流之上运行StreamSQL，其中简单的阈值以及跨所有流或特定流子集的聚合可以为某些用例带来巨大的价值。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
流处理引擎无法在同一规则中处理同步和异步事件。这意味着我们不能在执行规则时拦截流数据，同时调用外部API服务。流处理引擎被设计成专注于高吞吐量的流执行，对于任何对于给定事件有很大往返延迟的API调用，这只会破坏处理管道。
不过，流处理引擎有一种非常强大的查询语言StreamSQL。流上的StreamSQL查询通常是“连续的”，长时间执行并返回增量结果。这些操作包括：从流中选择、流关系连接、联合和合并、窗口和聚合操作。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
●流处理规则引擎不能在规则中表达不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
除非您是开发人员并熟悉streamsql，否则作为用户，不可能理解任何特定规则的行为。对于任何典型的基于SQL的解决方案，我们都可以这样认为，因此我们给它的总分是out。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
●API扩展和整体灵活性是这些规则引擎的弱点。流处理引擎是数据处理管道，并不意味着直接与第三方API系统集成。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
在许多IoT流处理用例中，流处理用于全局阈值交叉（例如，如果任何事件的温度高于阈值，则发送警报）或聚合（例如，给定区域的平均温度），但任何更复杂的计算或每设备的阈值交叉都极难实现。这就是为什么模板化、每台设备更新规则或版本更新非常困难。
. 体系结构可伸缩性（分片和分布式计算）
说到实时大容量数据处理能力，没有什么能比得上流处理引擎。
CEP发动机
尽管复杂事件处理引擎是流处理引擎的一部分（和前辈），但它处理事件的方式与它们更大和更年轻的同级引擎稍有不同（而且更好）。
我们看到CEP引擎正被部署在边缘计算中，在边缘计算中，局部性、低延迟和低硬件占用非常重要。当需要占用较少的内存时，cep是一个很好的选择，但是由于所有的事件处理都发生在内存中，所以不能很好地伸缩。
WSO、Litmus Automation和Foghorn是为边缘计算提供CEP规则引擎的供应商的例子。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
可以说，高阶逻辑结构（组合多个非二进制结果、多数表决、条件执行）是可能的，但由于CEP引擎的设计并没有考虑到这些特性，因此需要大量的难度和编码工作。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
CEP引擎通常在查询语言中集成了时间窗口和时态事件序列等内置运算符。CEP引擎和流处理引擎一样，不能处理规则中的异步和同步事件。他们也很难处理“过去”，也就是说在一段时间后，使事件失效。然而，与流处理引擎相比，它们通常具有更好的模式匹配能力，这使得在运行时能够更好地检测异常，因此我们给它们一个更好的分数，因为这是CEP引擎的优势之一。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
●CEP引擎不能在规则内表达不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
●CEP引擎的规则很难解释，因为所有的逻辑都深深地埋藏在代码中的某个地方。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
灵活性是这些规则引擎的一个弱点，但与流处理引擎相比，它在可扩展性方面排名更靠前，因为人们仍然可以想象出更好的API集成能力，主要是在可操作部分（如果出现问题，发送短信）。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
与流处理引擎类似，除了简单的用例外，可操作性是非常难以实现的，因为模板化、每个设备更新规则或版本更新都非常困难。
. 体系结构可伸缩性（分片和分布式计算）
当需要低占用空间时，cep非常适合，但是由于缺乏分布式计算能力以及它们处理内存中的所有数据而面临可伸缩性问题。
有限状态机
状态机可以用系统所经历的一组状态来描述系统。状态是对等待执行转换的系统状态的描述。转换是在满足条件或接收到事件时要执行的一组操作。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
有限状态机是为简单的关系建模，也就是从一种状态到另一种状态的转换，主要用于建模业务流程。结合多个非二进制结果和多数表决是不可能与有限状态机引擎。条件执行就是它们所能做的（每个转换都定义了条件）。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
●FSM引擎不能在规则中表示时间，除非我们讨论基于日/周/月时间的状态转换。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
●FSM引擎不能在规则内表达不确定性或效用函数。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
FSM的概念很容易被不同类型的用户理解。BREs（业务规则引擎）的主要卖点是BRE软件允许非程序员在业务流程管理（BPM）系统中实现业务逻辑。
FSM经常忽略的一点是状态意味着转换，也就是说，将某个事物建模为状态的唯一目的是导航特定的决策流。
其直接结果是，随着规则变得越来越复杂，或者当一个特定的角落案例需要被建模为一个状态时，FSM缺乏可读性。由于FSM一次只能执行一个转换，所以当用户试图引入某些情况下可能发生的事件时，需要添加一个新的状态。当状态数目变得太大时，状态机的可读性会显著下降。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
添加第三方API服务非常容易，因为API扩展需要最少的抽象
（任何给定输入的条件结果，在一组可用状态中解析）。然而，灵活性并不是强项，因为一旦规则被实现就很难改变。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
只要阈值和所有其他条件不变，就可以在许多设备上应用相同的规则。使用这样的规则很容易实现模板化和可搜索性，但是版本控制和执行批量升级就比较困难了，因为条件和阈值通常是全局变量，很难根据运行规则的每个实例进行更改。
. 体系结构可伸缩性（分片和分布式计算）
和FBP引擎一样，FSM引擎可以分发功能计算（状态执行）。另一方面，在一个规则内，所有的执行都是顺序的。FSM不是无状态的，这意味着规则引擎需要跟踪当前规则的执行情况，并在每次函数调用后应用转换以委托给下一个节点。
Waylay引擎
Waylay物联网规则引擎是一个基于贝叶斯网络（BN）的推理引擎。它允许向后和向前推理（状态传播），从而使推（数据流）和拉模式（API同步调用）都被视为第一类公民。
Waylay IoT规则引擎在现成的BNs上提供了三个重要的抽象：
●Waylay IoT规则引擎使用由传感器、逻辑和执行器组成的智能代理概念对规则进行建模。它将逻辑与感测和驱动解耦。因此，传感器和执行器可以很容易地跨规则重用。
●Waylay IoT规则引擎通过简化的条件概率表（CPT）对变量（传感器）的联合关系进行建模，并允许非常简单的紧凑逻辑表示，通过使用DAG模型进一步增强。
●Waylay IoT规则引擎对信息流、控制流和决策流进行独立建模。这使规则设计者能够完全控制规则的执行。
Waylay规则引擎具有以下关键特性：
●与流量规则引擎不同，没有左右输入/输出逻辑。信息流总是发生在各个方向。
●与流量规则引擎不同，Waylay规则引擎不需要“喷油器节点”或
“拆分/合并”输入/输出节点，以处理多种可能的结果。
●与前向链接算法或决策树不同，Waylay规则引擎不会通过分支所有可能的结果来建模逻辑。
●当对具有多个状态的多变量条件进行建模时，Waylay规则引擎不会像决策树一样遭受图大小的指数级爆炸。
●Waylay规则引擎是一个类似于FSM的状态传播引擎，但与FSM不同，它允许同时发生多个状态转换。
●与前向链接类似，Waylay规则引擎允许对多个条件进行建模，但决策过程并非由所有条件的模式匹配指导。
●Waylay规则引擎可以模拟可能性。
●与本文讨论的任何其他技术不同，Waylay规则引擎对信息流、控制流和决策流进行独立建模。
. 复杂逻辑建模
●结合规则中函数（观察）的多个非二进制结果
●处理规则中的多数表决条件
●根据先前观察结果处理函数的有条件执行
Waylay规则引擎将函数（观察）的多个非二进制结果组合到一个规则中，而不是布尔真/假状态。
通过聚合节点简化了变量的组合，这也提供了逻辑的紧凑表示。变量与其状态之间的关系用条件概率表（CPT）表示。条件依赖关系是用带有“简化”cpt的门来表示的（只包含0和1）。T
Waylay规则引擎定义了三种类型的门：AND、OR和GENERAL。事件尽管前两个（AND，OR）类似于布尔逻辑，但有两个重要区别：
●所有门可连接到“非二进制”传感器（具有两个以上状态的传感器）
●并非所有传感器都需要观察，以获得具有后验概率的门状态。
通用门允许同时对多个传感器结果和多数表决的组合进行建模。
关于这个功能的更多信息可以在这里找到
Waylay规则引擎通过将信息与控制流分离来处理基于先前观察结果的函数的有条件执行。例如，可以创建一个规则，其中某些传感器的执行取决于其他传感器的结果。附加传感器的状态转换也可以触发函数的有条件执行。这样一个规则的例子可以在这里找到。
. 建模时间
●处理过去（处理过期或即将过期的信息）
●处理当前（结合异步和同步信息）
●处理未来（异常值、时间窗口、拟合算法-预测和异常检测预测）
Waylay规则引擎通过逐出时间的概念来处理过去（过期或即将过期的信息）。逐出时间定义了传感器返回其先前位置的时间。例如，如果一个传感器有N个状态，系统将默认地假定在逐出时间之后，传感器在N个状态中的每个状态的概率为/N。如果没有定义驱逐时间，传感器将永远不会回到其先前的位置。
在处理损坏的传感器（例如，由于电池电量不足）、间歇性连接或无响应API时，驱逐时间非常有用。它允许您指定一段时间，在此期间您仍然可以依赖以前观察到的信息。它还提供了一种优雅的方式来合并来自不同传感器的流，例如在运动传感器的情况下，我们可以想象只有在同一时间窗口内从多个传感器注册运动时，规则才需要触发一个动作。
Waylay规则引擎还有一个嵌入式CEP引擎（称为公式节点），它将原始传感器测量值（而不仅仅是传感器状态）作为输入。CEP引擎应用复杂的统计公式，在时间或样本数量上进行聚合，或搜索特定模式（状态变化）。
处理当前（结合异步和同步信息）是现成的，开发人员不需要额外的努力来使用这个特性。
当SMS发送规则达到一定的限度时（例如，在与某个API集成时）。在Waylay规则引擎中，API也可以很容易地用作规则中的输入，例如，当将API调用的天气数据与来自传感器的流数据相结合时。对于信息的局部性非常重要的用例来说，这是一个重要的特性。
在异常检测和预测方面，Waylay规则引擎附带一个称为时间序列分析（Time Series Analytics）的特定模块，可对存储在Waylay时间序列数据库中的数据提供异常检测和预测等高级功能。通过传感器的概念，这些功能在Waylay规则引擎中自然暴露出来。规则设计者可以使用TSA并实现规则，例如：
●如果预测未来几周的能量消耗高于阈值，则发送SMS。
●创建Zendesk票证或发送电子邮件，如果传感器电池将在几周内达到%。
●如果检测到异常，则发出警报。
值得一提的是，拟合算法、异常定义和检测（无论我们假设异常是异常值，还是不遵循预期行为的东西，以及我们是否关注每个异常或我们搜索连续异常）和预测间隔都可以单独建模。
. 建模不确定性
●处理噪音数据或丢失数据
●处理效用函数
●处理概率推理（根据给定感官输出的不同结果的可能性构建逻辑）
当一个节点或一个门（多个节点之间的关系）处于给定状态且具有给定概率时，Waylay规则引擎允许通过分配执行器来进行概率推理。此外，您还可以将不同的执行器与图中任何节点的不同结果可能性关联起来。
. 可解释性
●规则的意图应向所有用户、开发者和企业所有者明确
●逻辑的紧凑表示
●模拟和调试能力
Waylay规则引擎提供了逻辑的紧凑表示。通过聚合节点组合两个变量（我们称之为传感器）。Waylay也是一个状态传播引擎，它允许通过跟踪状态的变化来轻松地解释规则。它还允许简单的调试和模拟，即使没有数据输入，只需在设计时跟踪任何给定传感器的状态变化。
. 适应性
●灵活性（支持技术和商业变更）
●可扩展性（与外部系统集成）
使用智能代理概念（由传感器、逻辑和执行器组成）对规则进行建模，可以方便地重用构建块：传感器和执行器。Waylay规则引擎提供了一个沙盒执行环境，最终用户可以轻松地基于外部api创建新的传感器和执行器。一旦创建，这些传感器和执行器可以很容易地在不同的规则之间共享。
. 可操作性
●将同一规则应用于多个设备或类似用例的模板
●模板和运行规则的版本控制，用于快照和回滚
●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力
●规则分析，以了解最触发的规则、最常见的行动等。
●跨规则组对生命周期mngt进行批量升级，对于更新或终止生命周期非常有用
传感器和执行器有版本。更新（传感器或执行器）插头时，新版本将存储在云中。然后，这些新版本可以重新应用到正在运行的规则中，并且没有停机时间。
模板是尚未与特定设备或实例关联的通用规则。所有模板都可以使用JSON表示进行存储和共享，而所有操作都通过api公开。Waylay规则引擎还附带了一个丰富的供应API模型，它对设备关系和规则继承进行建模。这样，通过将特定于设备的参数关联到特定的模板，同一模板可以作为任务多次实例化。
这个机制在操作上非常有效，因为模板只需要开发一次，但是可以多次实例化。例如，假设您为一个设备生成了一个模板，并且在该字段中部署了k个设备：那么您将有一个模板和k个任务在Waylay规则引擎上运行。
Waylay规则引擎的管理控制台提供当前运行的所有任务的清单，以及每个任务级别的生命周期管理：创建、删除、启动、停止、调试。此外，执行器日志提供已触发执行器的历史概述。
. 体系结构可伸缩性（分片和分布式计算）
Waylay规则引擎有三个组件：
●推理引擎（控制信息、控制和决策流）
●沙盒，外部API（传感器和执行器）以无状态方式执行，类似于lambda（云函数）架构
●时间序列分析引擎
结论
规则引擎是功能强大的自动化软件工具，有各种形状和风格。不同类型的引擎被用来解决不同的问题，有些引擎有重叠的功能。因此，很难找出哪种类型的规则引擎最适合物联网用例的需求。为了帮助您进行评估和决策过程，规则引擎定义了一个由七个核心规则引擎功能组成的基准：建模复杂逻辑、建模时间、建模不确定性、可解释性、适应性、可操作性和可扩展性。
