域名有了怎么建设网站,西安建厂,数据可视化网站,wordpress博客添加代码物联网应用程序设计与典型的IT解决方案大不相同#xff0c;因为它将物理操作技术#xff08;OT#xff09;与传感器、致动器和通信设备连接起来#xff0c;并将数字信息技术#xff08;IT#xff09;与数据、分析和工作流连接起来。在企业环境中#xff0c;物联网非常复…物联网应用程序设计与典型的IT解决方案大不相同因为它将物理操作技术OT与传感器、致动器和通信设备连接起来并将数字信息技术IT与数据、分析和工作流连接起来。在企业环境中物联网非常复杂这不仅是因为大型企业的物联网部署几乎肯定需要快速扩展到数千台然后数十万台设备或传感器或更多但也因为该解决方案需要跨所有其他企业系统工作并符合特定的企业软件要求。这两个世界之间的桥梁对于如何在物联网应用程序中构建业务逻辑和业务规则具有重要而独特的影响。可用于物联网领域的不同规则引擎技术。术语“规则引擎”的使用非常松散泛指自动化技术而不仅仅是典型的业务规则引擎。基准标准特定技术. 复杂逻辑建模●结合规则中函数观察的多个非二进制结果●处理规则中的多数表决条件●根据先前观察结果处理函数的有条件执行. 建模时间●处理过去处理过期或即将过期的信息●处理当前结合异步和同步信息●处理未来异常值、时间窗口、拟合算法-预测和异常检测预测. 建模不确定性●处理噪音数据或丢失数据●处理效用函数●处理概率推理根据给定感官输出的不同结果的可能性构建逻辑具体实施情况. 解释能力●规则的意图应向所有用户、开发者和企业所有者明确●逻辑的紧凑表示●设计期间和运行时的模拟和调试能力. 适应性●灵活性支持技术和商业变更●可扩展性与外部系统集成. 可操作性●将同一规则应用于多个设备或类似用例的模板●模板和运行规则的版本控制用于快照和回滚●可按名称、使用的API、设备类型和其他过滤器轻松搜索规则的搜索能力●规则分析以了解最触发的规则、最常见的行动等。●跨规则组对生命周期mngt进行批量升级对于更新或终止生命周期非常有用 基准中评估的规则引擎. 基于前向链接算法的规则引擎。目前市场上的大多数物联网平台都有这类规则引擎Redhat Drools、Cumulocity、Eclipse智能家居、AWS规则引擎、Thingsboard等。. 支持if/then或if/then/else模式的条件/操作规则引擎。即使它们只使用一个条件语句它们也可以被视为前向链接类别但我们将分别对它们进行评估因为FC引擎的大多数分数并不适用于它们。这组引擎的一个流行例子是物联网数字服务http://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 StormFlinkSamza等。当从数据流接收到事件时流处理应用程序立即对该事件作出反应。应用程序可能触发一个操作更新一个聚合或者“记住”事件以备将来使用。流处理计算还可以联合处理多个数据流并且事件数据流上的每个计算可以产生其他事件数据流。流处理引擎在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。TWaylay规则引擎定义了三种类型的门AND、OR和GENERAL。事件尽管前两个ANDOR类似于布尔逻辑但有两个重要区别●所有门可连接到“非二进制”传感器具有两个以上状态的传感器●并非所有传感器都需要观察以获得具有后验概率的门状态。 通用门允许同时对多个传感器结果和多数表决的组合进行建模。关于这个功能的更多信息可以在这里找到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云函数架构●时间序列分析引擎结论规则引擎是功能强大的自动化软件工具有各种形状和风格。不同类型的引擎被用来解决不同的问题有些引擎有重叠的功能。因此很难找出哪种类型的规则引擎最适合物联网用例的需求。为了帮助您进行评估和决策过程规则引擎定义了一个由七个核心规则引擎功能组成的基准建模复杂逻辑、建模时间、建模不确定性、可解释性、适应性、可操作性和可扩展性。 原文链接物联网规则引擎技术mp.weixin.qq.com往期精彩回顾智慧城市的定义是什么mp.weixin.qq.com设计成功物联网项目的基本要素mp.weixin.qq.com物联网设备mp.weixin.qq.com
