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

原文鏈接：

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

往期精彩回顧

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

總結(jié)

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

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