物聯(lián)網(wǎng)應用程序設計與典型的IT解決方案大不相同，因為它將物理操作技術（OT）與傳感器、致動器和通信設備連接起來，并將數(shù)字信息技術（IT）與數(shù)據(jù)、分析和工作流連接起來。
在企業(yè)環(huán)境中，物聯(lián)網(wǎng)非常復雜，這不僅是因為大型企業(yè)的物聯(lián)網(wǎng)部署幾乎肯定需要快速擴展到數(shù)千臺，然后數(shù)十萬臺設備（或傳感器）或更多，但也因為該解決方案需要跨所有其他企業(yè)系統(tǒng)工作，并符合特定的企業(yè)軟件要求。
這兩個世界之間的橋梁對于如何在物聯(lián)網(wǎng)應用程序中構建業(yè)務邏輯和業(yè)務規(guī)則具有重要而獨特的影響。可用于物聯(lián)網(wǎng)領域的不同規(guī)則引擎技術。術語“規(guī)則引擎”的使用非常松散，泛指自動化技術，而不僅僅是典型的業(yè)務規(guī)則引擎。基準標準特定技術. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）具體實施情況. 解釋能力
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●設計期間和運行時的模擬和調試能力. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用 基準中評估的規(guī)則引擎
. 基于前向鏈接算法的規(guī)則引擎。目前市場上的大多數(shù)物聯(lián)網(wǎng)平臺都有這類規(guī)則引擎：Redhat Drools、Cumulocity、Eclipse智能家居、AWS規(guī)則引擎、Thingsboard等。
. 支持if/then或if/then/else模式的條件/操作規(guī)則引擎。即使它們只使用一個條件語句，它們也可以被視為前向鏈接類別，但我們將分別對它們進行評估，因為FC引擎的大多數(shù)分數(shù)并不適用于它們。這組引擎的一個流行例子是物聯(lián)網(wǎng)數(shù)字服務http://ifttt.com網(wǎng)站。
. 基于流式編程（FBP）的規(guī)則引擎是由J.paulmorrison在上世紀年代在IBM發(fā)明的，其中最著名的例子就是Yahoo！管道和節(jié)點紅色。大多數(shù)SaaS自動化規(guī)則引擎都是這種類型的。并附帶說明了節(jié)點紅色與一般FBP類別的區(qū)別。
. 流處理規(guī)則引擎在數(shù)據(jù)產生或接收時直接處理動態(tài)數(shù)據(jù)。例如Apache Storm、Flink、Samza等。 . 復雜事件處理（CEP）引擎是流處理引擎的前身，在處理事件的方式上與它們不同。它們大多部署在邊緣計算中，例如WSO、Litmus或Foghorn。 . 有限狀態(tài)機（FSM）。狀態(tài)是對等待執(zhí)行轉換的系統(tǒng)狀態(tài)的描述。轉換是在滿足條件或接收到事件時要執(zhí)行的一組操作。業(yè)務規(guī)則引擎（BRE）是FSM的一個例子，它允許非程序員更改業(yè)務流程管理（BPM）系統(tǒng)中的業(yè)務邏輯。另一個例子是AWS Step函數(shù)，它將工作流轉換為狀態(tài)機圖。Salesforce的IoT Explorer也是一個基于FSM的規(guī)則引擎。 .決策樹（Decision tables）是一種簡明的可視化表示，用于根據(jù)給定的條件指定要執(zhí)行的操作。它們是算法，其輸出是一組動作。決策表中表達的信息也可以表示為決策樹，或者在編程語言中表示為一系列if-then-else和switch-case語句。 . Waylay規(guī)則引擎*是一個推理引擎，它建立在一個獨特的視角上，結合了兩個關鍵的人工智能概念-貝葉斯網(wǎng)絡和智能代理概念。（“用于建模、實例化和/或執(zhí)行應用程序中的貝葉斯代理）。前鏈發(fā)動機
使用前向鏈接（FC）的推理機應用一組規(guī)則和事實來推斷結論，搜索規(guī)則直到找到IF子句為真的規(guī)則為止。將新的或現(xiàn)有的事實與規(guī)則進行匹配的過程稱為模式匹配，FC推理機通過各種算法（如Linear、Rete、Treat、Leaps等）進行匹配。 當發(fā)現(xiàn)某個條件為TRUE時，引擎執(zhí)行THEN子句，從而將新信息添加到其數(shù)據(jù)集中。換句話說，引擎從許多事實開始，并應用規(guī)則從這些事實中得出所有可能的結論。這就是“前向鏈接”這個名稱的由來——事實上，推理機從數(shù)據(jù)開始，并將其向前推到答案，而反向鏈接則相反。倒鏈側注
在后向鏈接中，系統(tǒng)從結論到事實反向工作，這種方法稱為目標驅動。與前向鏈接相比，請求的數(shù)據(jù)很少，但搜索的規(guī)則很多。在這個基準測試中，我們有意識地選擇不考慮反向鏈接規(guī)則，因為它們不適合動態(tài)情況，而且大多只作為決策中的專家系統(tǒng)使用。 . 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
在規(guī)則中組合多個非二進制函數(shù)結果（觀察值）是不可能的，因為條件應用于布爾（真/假）結果。 FC引擎幾乎在多數(shù)投票要求下“崩潰”，因為它們搜索推理規(guī)則，直到找到一個或多個IF子句為真的地方。這意味著多個潛在矛盾的規(guī)則可能同時觸發(fā)，引擎需要處理沖突解決方案來決定執(zhí)行哪一個。在這一組合中加入多數(shù)票太難處理了。 基于先前觀察結果有條件地執(zhí)行函數(shù)并不容易，例如FC規(guī)則引擎希望在評估規(guī)則時所有數(shù)據(jù)都存在。我們仍然給他們打滿分，因為他們?yōu)楸磉_條件（布爾）邏輯提供了一個很好的框架。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
FC引擎無法在一個規(guī)則中表達時間維度——所有通過前向鏈接建模的規(guī)則感覺就像它們在時間上被凍結了一樣。 . 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
●FC引擎不能在規(guī)則內表達不確定性或效用函數(shù)。 . 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
●設計期間
●運行時
對于簡單的問題，FC引擎為我們提供了設計規(guī)則的簡單方法。事實上，沒有比這類規(guī)則更容易掌握的了！然而，在規(guī)則中添加更多的條件語句會導致非常復雜的分析，這會阻礙對規(guī)則意圖的理解。 此外，規(guī)則的實際條件（通常包括閾值和其他布爾表達式）被寫入并隱藏在代碼中的某個地方，因此很難向外部觀察者公開。作為一種解決方法，在設計階段，規(guī)則通常被表示為帶有條件結果的圖形，并將其標記為“箭頭”。然而，一旦規(guī)則被實現(xiàn)，這些圖形就不可能被看到或檢查。 模擬、調試和決策跟蹤（為什么在運行時觸發(fā)規(guī)則）不是一項簡單的任務，因為數(shù)據(jù)決定了選擇和使用哪些規(guī)則的路徑。此外，如前所述，沖突解決需要預先選擇沖突解決策略，該策略不是規(guī)則的一部分，而是規(guī)則引擎的配置參數(shù)。 . 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
更改規(guī)則是可能的，但總是有問題的，因為每次規(guī)則中的條件發(fā)生更改時，都需要重新評估沖突解決方案。 將第三方API服務添加到前向鏈接引擎不是一項簡單的任務，它通常直接在代碼中完成，從而導致API端點在規(guī)則級別直接耦合。由于閾值和其他條件也經(jīng)常在代碼中定義，因此很難跨多個實例化規(guī)則重用相同的API服務。 . 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型等輕松搜索規(guī)則過濾器
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
只要閾值和其他條件不隨設備的變化，就可以在多個設備上應用相同的規(guī)則。任何更復雜的東西都很難用FC實現(xiàn)，因為規(guī)則的許多輸入都深深地埋藏在代碼中。. 體系結構可伸縮性（分片和分布式計算）
前向鏈接規(guī)則是無狀態(tài)的，這意味著您可以輕松地并行運行多個規(guī)則，但不能在執(zhí)行一個規(guī)則實例時將負載分配給不同的進程。條件作用發(fā)動機
盡管我們可以認為基于條件-動作（CA）的規(guī)則引擎屬于前向鏈接引擎組，但我們決定將它們作為一個單獨的類別進行評估，因為許多通用的FC注釋并不適用于它們。原因是條件操作規(guī)則引擎不允許多個條件，這一方面使它們的邏輯表達式能力非常有限，另一方面，可伸縮性更高。條件操作規(guī)則引擎（if this-then that）有時會用ELSE語句（if this-then-ELSE-that）進行擴展。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行 與FC引擎不同，CA引擎不能建模任何復雜的邏輯（組合多個非二進制結果、多數(shù)投票、條件執(zhí)行）。它們用于非常簡單的用例。 . 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
這些引擎解決時間維度問題的一個方法是，它們通常依賴外部觸發(fā)器來確定要執(zhí)行的規(guī)則。也就是說，規(guī)則的IF條件變成了WHEN條件（例如，天氣不好時，發(fā)出警報；當我回家時，打開燈）。在這些工具中，這通常被稱為觸發(fā)器，盡管我們可能會認為這不是規(guī)則引擎本身的一部分（因為它需要在其他地方編碼），但如何將時間維度引入規(guī)則引擎仍然是顯而易見的。 . 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
●CA規(guī)則引擎不能在規(guī)則中表達不確定性或效用函數(shù)。 . 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
就像前向鏈接引擎一樣，IFTTT這樣的CA引擎為我們提供了一種為簡單問題設計規(guī)則的簡單方法。沒有什么比這條規(guī)則更容易理解的了！. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
CA引擎既靈活又可擴展。添加第三方API服務相當簡單，因為API擴展需要最少的抽象（if和act部分）。然而，由于CA引擎的性質，在規(guī)則內使用API服務存在局限性。 大多數(shù)情況下，CA引擎使用API服務作為觸發(fā)動作，而不是作為輸入，因為只有一個條件輸入槽可用，在IoT用例中，通常由設備數(shù)據(jù)獲取。例如，一個典型的例子是，如果設備溫度高于此溫度，則調用外部API服務（SMS、電子郵件、支持票證等）。 當CA引擎將API服務的數(shù)據(jù)建模為輸入時，那么我們不能將此API服務輸入與設備數(shù)據(jù)相結合，因為使用了單個輸入插槽，因此我們只能將該設備用作執(zhí)行器（例如“打開燈”）。 . 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
只要閾值和所有其他條件不變，就可以在許多設備上應用相同的規(guī)則。使用這樣的規(guī)則引擎，模板化、版本控制和可搜索性相當容易實現(xiàn)，但批量升級更困難，因為條件和閾值通常是全局變量，很難根據(jù)運行規(guī)則的每個實例進行更改。 . 體系結構可伸縮性（分片和分布式計算）
CA規(guī)則是無狀態(tài)的，非常簡單，所以很容易擴展這些規(guī)則引擎。然而，它們并沒有得到這個類別的最大分數(shù)，因為可伸縮性實際上只通過一個規(guī)則引擎類別來實現(xiàn)，即流處理引擎。流處理引擎
基于流的編程（FBP）是一種編程范式，它將應用程序定義為“黑盒”進程的網(wǎng)絡。這些過程，a.ka。函數(shù)表示為通過消息傳遞跨預定義連接交換數(shù)據(jù)的節(jié)點。這些節(jié)點可以無休止地重新連接以形成不同的應用程序，而不必改變它們的相關功能。
因此，FBP自然是“面向組件的”。FBP的一些好處是：
●在不重寫部件的情況下更改連接接線。
●固有并發(fā)-適用于多核CPU世界。 雅虎！Pipes和Node RED是使用FBP范式構建的規(guī)則引擎的兩個示例。隨著“無服務器”計算的引入，FBP變得更加流行，在這種計算中，可以通過鏈接函數(shù)來構建云應用程序。
IBM的OpenWhisk是一個通過鏈接云函數(shù)（IBM稱之為actions）的基于流的編程的例子。另一種基于有限狀態(tài)機規(guī)則引擎（如AWS step函數(shù)）的無服務器編排方法將在后面討論。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
FBP沒有狀態(tài)和狀態(tài)轉換的概念。在規(guī)則中組合函數(shù)（觀察）的多個非二進制結果仍然是可能的，但必須在應用它的每個函數(shù)中進行編碼。這也意味著你必須在每一個需要為多選結果建模的函數(shù)上分支。這會導致非常繁忙的流程圖，很難理解，特別是因為邏輯是在函數(shù)本身和它們的“連接器”（connector）路徑執(zhí)行中表達的。這些連接線在某種程度上不僅暗示了信息流，而且也暗示了正在做出的決定。
與決策樹（將在后面進一步討論）類似，這種建模方法會隨著邏輯復雜性的增加而出現(xiàn)節(jié)點數(shù)量的指數(shù)增長。更糟糕的是，與決策樹不同，我們無法將函數(shù)結果作為狀態(tài)來跟蹤。對于這個缺點，沒有比使用node RED實現(xiàn)的稍微復雜一點的流，并計算節(jié)點和連接器的數(shù)量更好的說明了。node RED用or節(jié)點和連接器設計的簡單用例并不罕見，這些用例幾乎不能放在一個屏幕上。
只有引入將不同節(jié)點的輸出合并到一個單獨的合并節(jié)點的概念，流引擎中的多數(shù)投票才有可能實現(xiàn)。即使如此，它仍然有問題，因為它需要在合并節(jié)點的函數(shù)中編寫多數(shù)規(guī)則。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
流引擎幾乎不能處理時間維度的任何方面，因為FBP通過設計是一個無狀態(tài)規(guī)則引擎。在一些有限的用例中（很難擴展），您可以在一個時間窗口內合并流。. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
FBP規(guī)則不能表達規(guī)則中的不確定性或效用函數(shù)。. 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
對于簡單的用例，基于流的數(shù)據(jù)流表示感覺很自然，至少從信息流的角度來看是這樣。但是任何使用FPB創(chuàng)建復雜邏輯的嘗試都會使驗證預期邏輯變得非常困難。
盡管如此，通過查看流程圖來理解哪些決策是非常困難的。其主要原因是邏輯表示不緊湊，規(guī)則的驗證通常需要流式測試數(shù)據(jù)，然后在所有管道上驗證函數(shù)日志。
邏輯在流路徑（數(shù)據(jù)在處理節(jié)點之間傳輸）和每個節(jié)點中的有效負載處理之間被分割，這可能導致在處理節(jié)點之后采用不同的路徑。因此，調試和規(guī)則驗證成為一個非常乏味和容易出錯的過程。此外，我們不確定所有的角點情況（作為來自不同輸入的決策的輸出）都被用FBP表示的特定規(guī)則所覆蓋，這看起來就像基于FBP的規(guī)則驗證是一個NP-hard問題。. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
FBP引擎具有可重用的黑盒節(jié)點（函數(shù)）。然而，任何特定規(guī)則的部分更新仍然是困難和風險的，因為這通常意味著對圖形的重大更改和規(guī)則的重新驗證。。在某種程度上，這主要是因為對于大多數(shù)規(guī)則引擎來說
特別是FBP，可解釋性和靈活性之間有很高的相關性。
基于流的規(guī)則引擎很容易用第三方服務進行擴展，并且以一種優(yōu)雅的方式實現(xiàn)了可擴展性。. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
模板化很難實現(xiàn)，因為在處理有效負載在不同處理節(jié)點之間傳遞時發(fā)生的有效負載轉換時需要特別小心。此外，閾值和分支邏輯是同一有效負載處理流程的一部分，這使得抽象這種邏輯非常困難。正是因為這個原因，批量升級容易出錯，而且風險很大。. 體系結構可伸縮性（分片和分布式計算）
FBP引擎本質上是并發(fā)的，因為它們必須分布函數(shù)計算。它們也是無狀態(tài)的，這意味著規(guī)則引擎只需要跟蹤當前的執(zhí)行和需要執(zhí)行的進一步操作。另一方面，如果在一個規(guī)則中需要合并不同節(jié)點的多個輸出，或者當使用不同的路徑執(zhí)行引入決策分支時，規(guī)則引擎將需要將規(guī)則執(zhí)行的快照（范圍）保留在某個地方。流量引擎?zhèn)茸?#xff1a;節(jié)點紅色可操作性
節(jié)點RED比FBPs有更大的可操作性問題。主要原因是它的作者選擇讓不同的協(xié)議流作為輸入數(shù)據(jù)事件直接進入節(jié)點。這是故意這樣做的，以簡化協(xié)議終止，并允許在節(jié)點RED中執(zhí)行有效負載規(guī)范化。但這是一把雙刃劍。
一方面，它意味著依賴于協(xié)議的數(shù)據(jù)流可以由任何第三方實現(xiàn)并在node RED環(huán)境中立即使用。這就是為什么node RED今天在maker社區(qū)非常受歡迎的原因，也是為什么它是許多工業(yè)供應商門戶中事實上的工具。由于協(xié)議轉換和負載規(guī)范化在物聯(lián)網(wǎng)部署中非常重要，因此節(jié)點RED對于邊緣部署非常有價值。
另一方面，同樣的決定使得模板化變得更加困難：協(xié)議轉換和有效負載規(guī)范化需要與閾值定義和分支一起成為節(jié)點RED模板的一部分。體系結構可伸縮性（分片和分布式計算）
雖然很適合邊緣部署，但是現(xiàn)成的節(jié)點RED實例對于云來說是不可伸縮的。一些供應商提供云解決方案，在節(jié)點RED上實現(xiàn)切分，并將協(xié)議終止外部化在一個單獨的組件中。然而，當采用這種方法時，他們也可以切換回更通用的FPB引擎。決策樹/決策表
獲取條件規(guī)則復雜性的一種常用方法是使用決策樹，決策樹是使用分支方法來說明決策的每個可能結果的圖形。市場上有幾種產品提供基于決策樹/表的規(guī)則引擎。
Drools主要以其基于前向鏈接的規(guī)則引擎而聞名，它也有一個與決策表集成的擴展，它使用excel表與嵌入代碼片段相結合來適應任何額外的邏輯或所需的閾值。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
當每個變量的狀態(tài)數(shù)有限時（例如二進制是/否狀態(tài)），決策樹很有用，但當狀態(tài)數(shù)增加時，決策樹可能會變得壓倒性。這是因為樹的深度隨著變量的數(shù)量線性增長，而分支的數(shù)量卻在增長
與狀態(tài)數(shù)成指數(shù)關系。例如，對于布爾變量，有^=^=，，，，，不同的決策樹（在文獻中，通常稱為“決策樹的假設空間”問題）。
多數(shù)投票是不可能的，除非我們進一步分支，在這里，多個不同的結果也是樹結構的一部分。有條件的執(zhí)行應該是現(xiàn)成的。顧名思義，決策樹都是關于有條件執(zhí)行的。盡管如此，決策樹從來沒有在物聯(lián)網(wǎng)環(huán)境中實現(xiàn)。在專家系統(tǒng)中，決策是問答場景的結果，當新數(shù)據(jù)（問題）被提供給決策樹引擎時，邏輯將遵循條件執(zhí)行。另一方面，在物聯(lián)網(wǎng)環(huán)境中，我們向規(guī)則引擎提供數(shù)據(jù)，并期望決策結果返回。在這種情況下，我們討論決策表，這意味著我們將數(shù)據(jù)輸入決策表，結果（決策）立即返回。我們仍然給決策樹打滿分，因為可解釋性使決策樹在這種能力非常重要的用例中非常有吸引力（例如醫(yī)療保健等）。. 建模時間●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
我們不能用決策樹來建模時間維度，除非我們將時間信息作為節(jié)點包含在樹中（例如周末、星期幾、一天中的時間等）。即便如此，我們也不能用時間來表達我們潛在觀察結果的變化，因此這些都是不可能的：處理過去（處理過期或即將過期的信息）、處理現(xiàn)在（結合異步和同步信息）、處理未來（預測和異常檢測）。. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
決策樹使用白盒模型。重要的見解可以根據(jù)領域專家描述情況和他們對結果的偏好產生。但是決策樹是不穩(wěn)定的，這意味著數(shù)據(jù)的一個小的變化就可能導致最優(yōu)決策樹的結構發(fā)生很大的變化。它們通常也相對不準確。計算可能會變得非常復雜，特別是在許多值不確定和/或許多結果關聯(lián)的情況下。決策樹不能建模不確定性和效用函數(shù)，除非像時間信息一樣，在樹中添加這些作為決策節(jié)點，這會使決策表更加復雜。. 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
決策樹易于理解和解釋。人們只需簡單的解釋就可以理解決策樹模型。但是，一旦規(guī)則被實例化，決策就不能被看到或檢查，并且在設計階段只在圖中被標記為“箭頭”。當實現(xiàn)為決策表時，可解釋性進一步下降，因為表中的每一行都是一個規(guī)則，而該行中的每一列都是該規(guī)則的條件或操作。這會導致整個序列不清晰-決策表沒有給出總體情況。. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
決策樹主要用于圖形化知識表示。使用決策樹構建規(guī)則引擎非常困難，在其上構建應用程序則更加困難。它們很難與任何第三方系統(tǒng)一起擴展。而且，訓練數(shù)據(jù)的任何微小變化都會導致最優(yōu)決策樹結構的巨大變化。. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
在多個設備上應用相同的決策樹規(guī)則幾乎是不可能的，因為大多數(shù)決策樹通過將駐留在決策表中的邏輯與代碼中單獨定義的操作混合起來來實現(xiàn)規(guī)則，這使得管理整個過程變得非常困難。. 體系結構可伸縮性（分片和分布式計算）
決策樹規(guī)則是無狀態(tài)的，這意味著，理論上，并行運行多個規(guī)則應該很容易。但是，在規(guī)則的一個實例中，不能在執(zhí)行某個特定規(guī)則時將負載分配給不同的進程。事實上，樹的深度與變量的數(shù)量成線性增長，而分支的數(shù)量則隨著狀態(tài)的數(shù)量呈指數(shù)增長，這使得決策樹很難擴展，如果不是不可能的話。計算可能會變得非常復雜，特別是在許多值不確定和/或許多結果關聯(lián)的情況下。流處理引擎
流處理是對動態(tài)數(shù)據(jù)的處理——換句話說，在數(shù)據(jù)產生或接收時直接對其進行計算（與MapReduce數(shù)據(jù)庫（如Hadoop）不同，后者在靜止時處理數(shù)據(jù)）。
在流處理作為處理連續(xù)數(shù)據(jù)集的標準出現(xiàn)之前，這些數(shù)據(jù)流通常存儲在數(shù)據(jù)庫、文件系統(tǒng)或其他形式的大容量存儲中。然后應用程序將查詢存儲的數(shù)據(jù)或根據(jù)需要計算數(shù)據(jù)。這種方法的一個顯著缺點（廣泛稱為批處理）是在創(chuàng)建數(shù)據(jù)和使用數(shù)據(jù)進行分析或操作之間存在延遲。
在大多數(shù)流處理引擎中，用戶必須編寫代碼來創(chuàng)建運算符，將它們連接到
繪制并運行它們。然后引擎并行運行圖形。流處理示例
引擎有Apache Storm，Flink，Samza等。
當從數(shù)據(jù)流接收到事件時，流處理應用程序立即對該事件作出反應。應用程序可能觸發(fā)一個操作，更新一個聚合，或者“記住”事件以備將來使用。
流處理計算還可以聯(lián)合處理多個數(shù)據(jù)流，并且事件數(shù)據(jù)流上的每個計算可以產生其他事件數(shù)據(jù)流。
流處理引擎在IoT中的使用范圍很窄-用于IoT數(shù)據(jù)流的運行時處理。它們不是作為通用規(guī)則引擎設計的，例如不能直接在設備上啟動。
流處理規(guī)則引擎通常用于算法交易、市場數(shù)據(jù)分析、網(wǎng)絡監(jiān)控、監(jiān)控、電子欺詐檢測和預防、點擊流分析和實時合規(guī)（反洗錢）等應用。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
流規(guī)則引擎不可能有高階邏輯結構（組合多個非二進制結果、多數(shù)表決、條件執(zhí)行）。然而，開發(fā)人員可以在數(shù)據(jù)流之上運行StreamSQL，其中簡單的閾值以及跨所有流或特定流子集的聚合可以為某些用例帶來巨大的價值。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
流處理引擎無法在同一規(guī)則中處理同步和異步事件。這意味著我們不能在執(zhí)行規(guī)則時攔截流數(shù)據(jù)，同時調用外部API服務。流處理引擎被設計成專注于高吞吐量的流執(zhí)行，對于任何對于給定事件有很大往返延遲的API調用，這只會破壞處理管道。
不過，流處理引擎有一種非常強大的查詢語言StreamSQL。流上的StreamSQL查詢通常是“連續(xù)的”，長時間執(zhí)行并返回增量結果。這些操作包括：從流中選擇、流關系連接、聯(lián)合和合并、窗口和聚合操作。. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
●流處理規(guī)則引擎不能在規(guī)則中表達不確定性或效用函數(shù)。 . 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
除非您是開發(fā)人員并熟悉streamsql，否則作為用戶，不可能理解任何特定規(guī)則的行為。對于任何典型的基于SQL的解決方案，我們都可以這樣認為，因此我們給它的總分是out。. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
●API擴展和整體靈活性是這些規(guī)則引擎的弱點。流處理引擎是數(shù)據(jù)處理管道，并不意味著直接與第三方API系統(tǒng)集成。 . 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
在許多IoT流處理用例中，流處理用于全局閾值交叉（例如，如果任何事件的溫度高于閾值，則發(fā)送警報）或聚合（例如，給定區(qū)域的平均溫度），但任何更復雜的計算或每設備的閾值交叉都極難實現(xiàn)。這就是為什么模板化、每臺設備更新規(guī)則或版本更新非常困難。. 體系結構可伸縮性（分片和分布式計算）
說到實時大容量數(shù)據(jù)處理能力，沒有什么能比得上流處理引擎。CEP發(fā)動機
盡管復雜事件處理引擎是流處理引擎的一部分（和前輩），但它處理事件的方式與它們更大和更年輕的同級引擎稍有不同（而且更好）。
我們看到CEP引擎正被部署在邊緣計算中，在邊緣計算中，局部性、低延遲和低硬件占用非常重要。當需要占用較少的內存時，cep是一個很好的選擇，但是由于所有的事件處理都發(fā)生在內存中，所以不能很好地伸縮。
WSO、Litmus Automation和Foghorn是為邊緣計算提供CEP規(guī)則引擎的供應商的例子。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
可以說，高階邏輯結構（組合多個非二進制結果、多數(shù)表決、條件執(zhí)行）是可能的，但由于CEP引擎的設計并沒有考慮到這些特性，因此需要大量的難度和編碼工作。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
CEP引擎通常在查詢語言中集成了時間窗口和時態(tài)事件序列等內置運算符。CEP引擎和流處理引擎一樣，不能處理規(guī)則中的異步和同步事件。他們也很難處理“過去”，也就是說在一段時間后，使事件失效。然而，與流處理引擎相比，它們通常具有更好的模式匹配能力，這使得在運行時能夠更好地檢測異常，因此我們給它們一個更好的分數(shù)，因為這是CEP引擎的優(yōu)勢之一。. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
●CEP引擎不能在規(guī)則內表達不確定性或效用函數(shù)。. 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
●CEP引擎的規(guī)則很難解釋，因為所有的邏輯都深深地埋藏在代碼中的某個地方。 . 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
靈活性是這些規(guī)則引擎的一個弱點，但與流處理引擎相比，它在可擴展性方面排名更靠前，因為人們仍然可以想象出更好的API集成能力，主要是在可操作部分（如果出現(xiàn)問題，發(fā)送短信）。. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
與流處理引擎類似，除了簡單的用例外，可操作性是非常難以實現(xiàn)的，因為模板化、每個設備更新規(guī)則或版本更新都非常困難。. 體系結構可伸縮性（分片和分布式計算）
當需要低占用空間時，cep非常適合，但是由于缺乏分布式計算能力以及它們處理內存中的所有數(shù)據(jù)而面臨可伸縮性問題。有限狀態(tài)機
狀態(tài)機可以用系統(tǒng)所經(jīng)歷的一組狀態(tài)來描述系統(tǒng)。狀態(tài)是對等待執(zhí)行轉換的系統(tǒng)狀態(tài)的描述。轉換是在滿足條件或接收到事件時要執(zhí)行的一組操作。. 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
有限狀態(tài)機是為簡單的關系建模，也就是從一種狀態(tài)到另一種狀態(tài)的轉換，主要用于建模業(yè)務流程。結合多個非二進制結果和多數(shù)表決是不可能與有限狀態(tài)機引擎。條件執(zhí)行就是它們所能做的（每個轉換都定義了條件）。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
●FSM引擎不能在規(guī)則中表示時間，除非我們討論基于日/周/月時間的狀態(tài)轉換。 . 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
●FSM引擎不能在規(guī)則內表達不確定性或效用函數(shù)。 . 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
FSM的概念很容易被不同類型的用戶理解。BREs（業(yè)務規(guī)則引擎）的主要賣點是BRE軟件允許非程序員在業(yè)務流程管理（BPM）系統(tǒng)中實現(xiàn)業(yè)務邏輯。
FSM經(jīng)常忽略的一點是狀態(tài)意味著轉換，也就是說，將某個事物建模為狀態(tài)的唯一目的是導航特定的決策流。
其直接結果是，隨著規(guī)則變得越來越復雜，或者當一個特定的角落案例需要被建模為一個狀態(tài)時，FSM缺乏可讀性。由于FSM一次只能執(zhí)行一個轉換，所以當用戶試圖引入某些情況下可能發(fā)生的事件時，需要添加一個新的狀態(tài)。當狀態(tài)數(shù)目變得太大時，狀態(tài)機的可讀性會顯著下降。. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
添加第三方API服務非常容易，因為API擴展需要最少的抽象
（任何給定輸入的條件結果，在一組可用狀態(tài)中解析）。然而，靈活性并不是強項，因為一旦規(guī)則被實現(xiàn)就很難改變。. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用 只要閾值和所有其他條件不變，就可以在許多設備上應用相同的規(guī)則。使用這樣的規(guī)則很容易實現(xiàn)模板化和可搜索性，但是版本控制和執(zhí)行批量升級就比較困難了，因為條件和閾值通常是全局變量，很難根據(jù)運行規(guī)則的每個實例進行更改。. 體系結構可伸縮性（分片和分布式計算）
和FBP引擎一樣，FSM引擎可以分發(fā)功能計算（狀態(tài)執(zhí)行）。另一方面，在一個規(guī)則內，所有的執(zhí)行都是順序的。FSM不是無狀態(tài)的，這意味著規(guī)則引擎需要跟蹤當前規(guī)則的執(zhí)行情況，并在每次函數(shù)調用后應用轉換以委托給下一個節(jié)點。Waylay引擎
Waylay物聯(lián)網(wǎng)規(guī)則引擎是一個基于貝葉斯網(wǎng)絡（BN）的推理引擎。它允許向后和向前推理（狀態(tài)傳播），從而使推（數(shù)據(jù)流）和拉模式（API同步調用）都被視為第一類公民。Waylay IoT規(guī)則引擎在現(xiàn)成的BNs上提供了三個重要的抽象：
●Waylay IoT規(guī)則引擎使用由傳感器、邏輯和執(zhí)行器組成的智能代理概念對規(guī)則進行建模。它將邏輯與感測和驅動解耦。因此，傳感器和執(zhí)行器可以很容易地跨規(guī)則重用。
●Waylay IoT規(guī)則引擎通過簡化的條件概率表（CPT）對變量（傳感器）的聯(lián)合關系進行建模，并允許非常簡單的緊湊邏輯表示，通過使用DAG模型進一步增強。
●Waylay IoT規(guī)則引擎對信息流、控制流和決策流進行獨立建模。這使規(guī)則設計者能夠完全控制規(guī)則的執(zhí)行。 Waylay規(guī)則引擎具有以下關鍵特性：
●與流量規(guī)則引擎不同，沒有左右輸入/輸出邏輯。信息流總是發(fā)生在各個方向。
●與流量規(guī)則引擎不同，Waylay規(guī)則引擎不需要“噴油器節(jié)點”或“拆分/合并”輸入/輸出節(jié)點，以處理多種可能的結果。
●與前向鏈接算法或決策樹不同，Waylay規(guī)則引擎不會通過分支所有可能的結果來建模邏輯。
●當對具有多個狀態(tài)的多變量條件進行建模時，Waylay規(guī)則引擎不會像決策樹一樣遭受圖大小的指數(shù)級爆炸。
●Waylay規(guī)則引擎是一個類似于FSM的狀態(tài)傳播引擎，但與FSM不同，它允許同時發(fā)生多個狀態(tài)轉換。
●與前向鏈接類似，Waylay規(guī)則引擎允許對多個條件進行建模，但決策過程并非由所有條件的模式匹配指導。
●Waylay規(guī)則引擎可以模擬可能性。
●與本文討論的任何其他技術不同，Waylay規(guī)則引擎對信息流、控制流和決策流進行獨立建模。 . 復雜邏輯建模
●結合規(guī)則中函數(shù)（觀察）的多個非二進制結果
●處理規(guī)則中的多數(shù)表決條件
●根據(jù)先前觀察結果處理函數(shù)的有條件執(zhí)行
Waylay規(guī)則引擎將函數(shù)（觀察）的多個非二進制結果組合到一個規(guī)則中，而不是布爾真/假狀態(tài)。
通過聚合節(jié)點簡化了變量的組合，這也提供了邏輯的緊湊表示。變量與其狀態(tài)之間的關系用條件概率表（CPT）表示。條件依賴關系是用帶有“簡化”cpt的門來表示的（只包含0和1）。T
Waylay規(guī)則引擎定義了三種類型的門：AND、OR和GENERAL。事件盡管前兩個（AND，OR）類似于布爾邏輯，但有兩個重要區(qū)別：
●所有門可連接到“非二進制”傳感器（具有兩個以上狀態(tài)的傳感器）
●并非所有傳感器都需要觀察，以獲得具有后驗概率的門狀態(tài)。
通用門允許同時對多個傳感器結果和多數(shù)表決的組合進行建模。
關于這個功能的更多信息可以在這里找到
Waylay規(guī)則引擎通過將信息與控制流分離來處理基于先前觀察結果的函數(shù)的有條件執(zhí)行。例如，可以創(chuàng)建一個規(guī)則，其中某些傳感器的執(zhí)行取決于其他傳感器的結果。附加傳感器的狀態(tài)轉換也可以觸發(fā)函數(shù)的有條件執(zhí)行。這樣一個規(guī)則的例子可以在這里找到。. 建模時間
●處理過去（處理過期或即將過期的信息）
●處理當前（結合異步和同步信息）
●處理未來（異常值、時間窗口、擬合算法-預測和異常檢測預測）
Waylay規(guī)則引擎通過逐出時間的概念來處理過去（過期或即將過期的信息）。逐出時間定義了傳感器返回其先前位置的時間。例如，如果一個傳感器有N個狀態(tài)，系統(tǒng)將默認地假定在逐出時間之后，傳感器在N個狀態(tài)中的每個狀態(tài)的概率為/N。如果沒有定義驅逐時間，傳感器將永遠不會回到其先前的位置。
在處理損壞的傳感器（例如，由于電池電量不足）、間歇性連接或無響應API時，驅逐時間非常有用。它允許您指定一段時間，在此期間您仍然可以依賴以前觀察到的信息。它還提供了一種優(yōu)雅的方式來合并來自不同傳感器的流，例如在運動傳感器的情況下，我們可以想象只有在同一時間窗口內從多個傳感器注冊運動時，規(guī)則才需要觸發(fā)一個動作。
Waylay規(guī)則引擎還有一個嵌入式CEP引擎（稱為公式節(jié)點），它將原始傳感器測量值（而不僅僅是傳感器狀態(tài)）作為輸入。CEP引擎應用復雜的統(tǒng)計公式，在時間或樣本數(shù)量上進行聚合，或搜索特定模式（狀態(tài)變化）。
處理當前（結合異步和同步信息）是現(xiàn)成的，開發(fā)人員不需要額外的努力來使用這個特性。
當SMS發(fā)送規(guī)則達到一定的限度時（例如，在與某個API集成時）。在Waylay規(guī)則引擎中，API也可以很容易地用作規(guī)則中的輸入，例如，當將API調用的天氣數(shù)據(jù)與來自傳感器的流數(shù)據(jù)相結合時。對于信息的局部性非常重要的用例來說，這是一個重要的特性。
在異常檢測和預測方面，Waylay規(guī)則引擎附帶一個稱為時間序列分析（Time Series Analytics）的特定模塊，可對存儲在Waylay時間序列數(shù)據(jù)庫中的數(shù)據(jù)提供異常檢測和預測等高級功能。通過傳感器的概念，這些功能在Waylay規(guī)則引擎中自然暴露出來。規(guī)則設計者可以使用TSA并實現(xiàn)規(guī)則，例如：
●如果預測未來幾周的能量消耗高于閾值，則發(fā)送SMS。
●創(chuàng)建Zendesk票證或發(fā)送電子郵件，如果傳感器電池將在幾周內達到%。
●如果檢測到異常，則發(fā)出警報。
值得一提的是，擬合算法、異常定義和檢測（無論我們假設異常是異常值，還是不遵循預期行為的東西，以及我們是否關注每個異常或我們搜索連續(xù)異常）和預測間隔都可以單獨建模。. 建模不確定性
●處理噪音數(shù)據(jù)或丟失數(shù)據(jù)
●處理效用函數(shù)
●處理概率推理（根據(jù)給定感官輸出的不同結果的可能性構建邏輯）
當一個節(jié)點或一個門（多個節(jié)點之間的關系）處于給定狀態(tài)且具有給定概率時，Waylay規(guī)則引擎允許通過分配執(zhí)行器來進行概率推理。此外，您還可以將不同的執(zhí)行器與圖中任何節(jié)點的不同結果可能性關聯(lián)起來。. 可解釋性
●規(guī)則的意圖應向所有用戶、開發(fā)者和企業(yè)所有者明確
●邏輯的緊湊表示
●模擬和調試能力
Waylay規(guī)則引擎提供了邏輯的緊湊表示。通過聚合節(jié)點組合兩個變量（我們稱之為傳感器）。Waylay也是一個狀態(tài)傳播引擎，它允許通過跟蹤狀態(tài)的變化來輕松地解釋規(guī)則。它還允許簡單的調試和模擬，即使沒有數(shù)據(jù)輸入，只需在設計時跟蹤任何給定傳感器的狀態(tài)變化。. 適應性
●靈活性（支持技術和商業(yè)變更）
●可擴展性（與外部系統(tǒng)集成）
使用智能代理概念（由傳感器、邏輯和執(zhí)行器組成）對規(guī)則進行建模，可以方便地重用構建塊：傳感器和執(zhí)行器。Waylay規(guī)則引擎提供了一個沙盒執(zhí)行環(huán)境，最終用戶可以輕松地基于外部api創(chuàng)建新的傳感器和執(zhí)行器。一旦創(chuàng)建，這些傳感器和執(zhí)行器可以很容易地在不同的規(guī)則之間共享。. 可操作性
●將同一規(guī)則應用于多個設備或類似用例的模板
●模板和運行規(guī)則的版本控制，用于快照和回滾
●可按名稱、使用的API、設備類型和其他過濾器輕松搜索規(guī)則的搜索能力
●規(guī)則分析，以了解最觸發(fā)的規(guī)則、最常見的行動等。
●跨規(guī)則組對生命周期mngt進行批量升級，對于更新或終止生命周期非常有用
傳感器和執(zhí)行器有版本。更新（傳感器或執(zhí)行器）插頭時，新版本將存儲在云中。然后，這些新版本可以重新應用到正在運行的規(guī)則中，并且沒有停機時間。
模板是尚未與特定設備或實例關聯(lián)的通用規(guī)則。所有模板都可以使用JSON表示進行存儲和共享，而所有操作都通過api公開。Waylay規(guī)則引擎還附帶了一個豐富的供應API模型，它對設備關系和規(guī)則繼承進行建模。這樣，通過將特定于設備的參數(shù)關聯(lián)到特定的模板，同一模板可以作為任務多次實例化。
這個機制在操作上非常有效，因為模板只需要開發(fā)一次，但是可以多次實例化。例如，假設您為一個設備生成了一個模板，并且在該字段中部署了k個設備：那么您將有一個模板和k個任務在Waylay規(guī)則引擎上運行。
Waylay規(guī)則引擎的管理控制臺提供當前運行的所有任務的清單，以及每個任務級別的生命周期管理：創(chuàng)建、刪除、啟動、停止、調試。此外，執(zhí)行器日志提供已觸發(fā)執(zhí)行器的歷史概述。. 體系結構可伸縮性（分片和分布式計算）
Waylay規(guī)則引擎有三個組件：
●推理引擎（控制信息、控制和決策流）
●沙盒，外部API（傳感器和執(zhí)行器）以無狀態(tài)方式執(zhí)行，類似于lambda（云函數(shù)）架構
●時間序列分析引擎結論
規(guī)則引擎是功能強大的自動化軟件工具，有各種形狀和風格。不同類型的引擎被用來解決不同的問題，有些引擎有重疊的功能。因此，很難找出哪種類型的規(guī)則引擎最適合物聯(lián)網(wǎng)用例的需求。為了幫助您進行評估和決策過程，規(guī)則引擎定義了一個由七個核心規(guī)則引擎功能組成的基準：建模復雜邏輯、建模時間、建模不確定性、可解釋性、適應性、可操作性和可擴展性。

原文鏈接：

物聯(lián)網(wǎng)規(guī)則引擎技術?mp.weixin.qq.com

往期精彩回顧

智慧城市的定義是什么？?mp.weixin.qq.com設計成功物聯(lián)網(wǎng)項目的基本要素?mp.weixin.qq.com物聯(lián)網(wǎng)設備?mp.weixin.qq.com

總結

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

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