物聯網應用程序設計與典型的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 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（云函數）架構
●時間序列分析引擎結論
規則引擎是功能強大的自動化軟件工具，有各種形狀和風格。不同類型的引擎被用來解決不同的問題，有些引擎有重疊的功能。因此，很難找出哪種類型的規則引擎最適合物聯網用例的需求。為了幫助您進行評估和決策過程，規則引擎定義了一個由七個核心規則引擎功能組成的基準：建模復雜邏輯、建模時間、建模不確定性、可解釋性、適應性、可操作性和可擴展性。

原文鏈接：

物聯網規則引擎技術?mp.weixin.qq.com

往期精彩回顧

智慧城市的定義是什么？?mp.weixin.qq.com設計成功物聯網項目的基本要素?mp.weixin.qq.com物聯網設備?mp.weixin.qq.com

總結

以上是生活随笔為你收集整理的drools规则引擎技术指南_物联网规则引擎技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。