王 博,張 昱,耿佳寧,李向陽
1(中國科學(xué)技術(shù)大學(xué) 計算機科學(xué)與技術(shù)學(xué)院 下一代移動計算與數(shù)據(jù)創(chuàng)新實驗室,安徽 合肥 230027)
2(中國科學(xué)院 無線光電通信重點實驗室,安徽 合肥 230027)
隨著物聯(lián)網(wǎng)、人工智能與5G 等創(chuàng)新技術(shù)驅(qū)動的萬物互聯(lián)時代的到來,智能家居作為物聯(lián)網(wǎng)的重要應(yīng)用場景之一,正快速進(jìn)入千家萬戶.智能家居令家庭中的各種設(shè)備互聯(lián)互通,使用戶實現(xiàn)設(shè)備的自動控制、遠(yuǎn)程控制和可編程控制,甚至可以根據(jù)歷史經(jīng)驗主動進(jìn)行自動化服務(wù).根據(jù)MarketWatch 發(fā)布的報告[1],2016 年,全球智能家居市值556.5 億美元,預(yù)計2025 年將達(dá)到1 742.4 億美元;同時,中國的智能家居市場也在快速發(fā)展,據(jù)艾瑞咨詢發(fā)布的報告[2],2017 年,中國智能家居市場規(guī)模為3 254.7 億元,預(yù)計2020 年將達(dá)到5 819.3 億元.
為管理種類和規(guī)模不斷增加的智能設(shè)備,國內(nèi)外主要領(lǐng)導(dǎo)廠商紛紛推出智能家居平臺,如三星的SmartThings、Amazon 的Alexa、Google 的Home、小米的米家、華為HiLink、云端規(guī)則定制平臺IFTTT(“IF This Then That”)[3]等,但它們幾乎不開源并且僅支持相關(guān)品牌的設(shè)備,限制了用戶所能管控的設(shè)備類型及范圍;在開源的智能家居平臺中,基于Python3 的HomeAssistant[4]相對成熟,支持多種操作系統(tǒng)/平臺,集成了IFTTT、GoogleAssistant、MQTT 等產(chǎn)品/功能.這些智能家居平臺將要管控的設(shè)備抽象化,通過建立通信標(biāo)準(zhǔn)以及API互聯(lián)等方式連接設(shè)備和app,采用“觸發(fā)-動作編程”(trigger-action programming,簡稱TAP)[5]支持用戶定制規(guī)則以指定系統(tǒng)行為.但我們通過多次調(diào)研發(fā)現(xiàn):現(xiàn)有TAP 雖足以滿足終端用戶表達(dá)簡單的自動化任務(wù),但靈活性不足,難以支持更復(fù)雜的用例[5-8].
TAP 規(guī)則(如IFTTT)典型地將單個觸發(fā)器(trigger)與單個動作(action)關(guān)聯(lián)起來,例如“如果開始下雨,則關(guān)窗”.然而,許多常見行為需要TAP 提供更強的表達(dá)能力,如對空調(diào)等復(fù)雜設(shè)備的設(shè)定、對門鎖窗戶等安全攸關(guān)設(shè)備的可靠設(shè)定、對夜燈/咖啡機等設(shè)備的工作持續(xù)時間設(shè)定等.為支持用戶的日常需求,不同的智能家居平臺提供不同的支持,例如引入and 連接多個觸發(fā)器[5]或者連接多個觸發(fā)器和多個動作(如Stringify[9])、用更一般的and/or 組合多個觸發(fā)器或多個動作(如HomeAssistant)、增加對觸發(fā)器的條件過濾(如Microsoft Flow[10],Zapier[11]和 HomeAssistant)、增加“狀態(tài)保持時長”的表達(dá)能力(如 SmartRules[12])、支持自定義的事件/服務(wù)(如HomeAssistant).各種TAP 擴展豐富了可定制性,但是也存在語義不清晰、編寫復(fù)雜等缺陷,不便于用戶使用.
隨著設(shè)備數(shù)量的增加,其交互也隨之增多,TAP 編程出錯的可能性也會增加.針對這類問題,一些研究如BuildingRules[13],IRuler[14]等提供對某些TAP 編程缺陷的檢測;AutoTap[15]能由線性時序邏輯表達(dá)的設(shè)備性質(zhì)合成某些TAP 規(guī)則,從而避免用戶直接編寫TAP 規(guī)則;AutoTap 和Menshen[16]還提供有限的錯誤修復(fù)功能.Brackenbury 等人[17]首次提出和規(guī)范可用于TAP 規(guī)則觸發(fā)器的3 種時序范式Event-Event,State-State 和Event- State,并總結(jié)了TAP 可能存在的10 種編程缺陷.
針對智能家居系統(tǒng)面臨的挑戰(zhàn),本文研究易寫易改、支持多觸發(fā)器-多動作、支持狀態(tài)保持描述等能力的TAP 規(guī)則的表示,然后構(gòu)建支持這種規(guī)則表示的智能家居自動化框架.在TAP 規(guī)則的表示方面,觸發(fā)器和動作均可以分為(純)狀態(tài)型和事件型.本文首先系統(tǒng)分析和總結(jié)了各種TAP 編程范式以及它們引起的缺陷種類、原因和檢測/修復(fù)現(xiàn)狀,指出了改進(jìn)TAP 的可能渠道;然后,針對用戶不易分清事件和狀態(tài)、不易寫全規(guī)則所要考慮的情況組合以及“Event-trigger Event-action”(EE)風(fēng)格的規(guī)則冗長、更改瑣碎等特征,本文提出以“State-trigger State-action”(SS)為基礎(chǔ)構(gòu)建面向終端用戶易寫易改的、具有豐富表達(dá)能力的具體SS 規(guī)則范式.在自動化框架構(gòu)建方面,鑒于HomeAssistant(簡稱HA)相對成熟和開源,支持多種平臺和多種設(shè)備及服務(wù)集成方式,提供以Event 為核心的寬泛TAP 配置,本文以它為基礎(chǔ)構(gòu)建支持SS 規(guī)則范式的智能家居自動化框架SSRules.針對Brackenbury 等人[17]指出的10 種TAP 缺陷,采用SS 規(guī)則范式能天然排除時間窗錯誤和翻轉(zhuǎn)觸發(fā)器這2 種缺陷,完全避免優(yōu)先級沖突;結(jié)合SSRules 的實現(xiàn)策略,能部分解決或消除安全默認(rèn)偏差、非瞬時動作、重復(fù)觸發(fā)這3種缺陷,并附帶改善缺少反向動作的缺陷;對于無限循環(huán)和不確定時序這兩種缺陷,可以通過模型檢查等方法在規(guī)則轉(zhuǎn)譯成HA 之前避免;SSRules 尚不能解決矛盾的動作這種缺陷.本文的主要貢獻(xiàn)如下:
(1) 系統(tǒng)分析和總結(jié)了TAP 編程范式及其編程缺陷,指出了改進(jìn)TAP 的幾種可能渠道,為我國智能家居領(lǐng)域從業(yè)者和軟件研發(fā)人員全面了解TAP 編程、缺陷及改進(jìn)提供了參考資料;
(2) 提出以“State-trigger State-action”為基礎(chǔ)構(gòu)建易寫易改、有豐富表達(dá)力的TAP 編程范式.SS 規(guī)則范式以實體-能力抽象為基礎(chǔ),按動作實體將規(guī)則分組、組內(nèi)按序優(yōu)先,有效避免了優(yōu)先級沖突;它區(qū)分只讀和可控能力,提供4 種表示歷史狀態(tài)的算符,并方便表達(dá)在指定狀態(tài)/狀態(tài)保持下對多種能力的期望;
(3) 引入能表達(dá)事件型智能家居執(zhí)行引擎的獨立“Event-trigger Event-action”(EE)中間表示,基于HA 構(gòu)建智能家居自動化框架SSRules,它能將SS 規(guī)則集合經(jīng)EE 規(guī)則表示轉(zhuǎn)譯成HA 規(guī)則,利用Z3 定理證明器[18]進(jìn)行觸發(fā)事件的篩選和規(guī)則化簡,并提供運行時子系統(tǒng)動態(tài)感知設(shè)備變化和檢查規(guī)則執(zhí)行的有效性;
(4) 實現(xiàn)了智能家居模擬器和SSRules 原型系統(tǒng).對10 組測試場景,用SS 范式編寫所需的規(guī)則條數(shù)比轉(zhuǎn)譯和合并后得到的EE 范式規(guī)則數(shù)平均減少了60%左右;在模擬實驗環(huán)境下,最終生成的HA 規(guī)則的運行時檢查都未發(fā)現(xiàn)連續(xù)異常,并且所記錄到的瞬時異常(小于總檢查次數(shù)的0.3%)經(jīng)查閱日志均為網(wǎng)絡(luò)延遲引起.
本文第1 節(jié)對現(xiàn)有TAP 編程范式及其引起的缺陷、易用性以及缺陷檢查和修復(fù)現(xiàn)狀進(jìn)行總結(jié).第2 節(jié)提出智能家居自動化框架的設(shè)計目標(biāo),對以HA 為底層基礎(chǔ)、以SS 規(guī)則范式為用戶輸入的智能家居自動化框架SSRules 的總體設(shè)計進(jìn)行總結(jié).第3 節(jié)詳細(xì)討論SS 規(guī)則范式的定義及其到HA 規(guī)則的轉(zhuǎn)譯方法.第4 節(jié)介紹基于HA 構(gòu)建的智能家居模擬環(huán)境,并在該模擬環(huán)境上評估了SSRules 的有效性.第5 節(jié)和第6 節(jié)分別對相關(guān)工作和本文的工作進(jìn)行總結(jié).
為了滿足終端用戶靈活多樣的需求,大多數(shù)智能家居平臺都提供特定的TAP 編程接口用于對智能設(shè)備和/或服務(wù)進(jìn)行編程,以定制智能家居系統(tǒng)的行為.本節(jié)首先對TAP 編程范式進(jìn)行了詳細(xì)分析,然后系統(tǒng)總結(jié)分析了可能導(dǎo)致TAP 缺陷的原因,最后簡要總結(jié)改進(jìn)TAP 的可能渠道.
1.1 TAP編程范式概述
TAP 的表達(dá)能力及易寫易改性,對智能家居的推廣和普及至關(guān)重要.目前最流行的TAP 接口是IFTTT 在線服務(wù)[3],它允許用戶創(chuàng)建程序、自動執(zhí)行由單個事件觸發(fā)的動作,盡管IFTTT 應(yīng)用廣泛,但其表達(dá)能力非常受限.
? 多觸發(fā)器、多動作
根據(jù)Ur 等人的用戶調(diào)查[5],22%的編程行為需要不止一個觸發(fā)器或動作,并且觸發(fā)器和動作在用戶期望的行為中的組合也更為多樣化.因此,Ur 等人引入“and”連接觸發(fā)同一動作的多個事件,例如“IF 窗戶是開的and 在下雨”就觸發(fā)“關(guān)窗”.Zapier[11]允許將多個動作綁定到一個觸發(fā)器;Stringify[9]支持形如“If This and This,Then That and That”的規(guī)則.HA[4]還允許定制只要多個觸發(fā)器中任意一個被觸發(fā)就執(zhí)行的規(guī)則.
? 條件過濾與工作流控制
Zapier 和HA 提供過濾器,支持對觸發(fā)器的進(jìn)一步(and/or)條件過濾.例如:可以在觸發(fā)器“接收郵件”后追加過濾器“主題包含X and 來自Y”;MicrosoftFlow[10]不僅提供多步驟的工作流,還提供If-then-else 條件過濾、For-Each 和Do-While 循環(huán)等;HA 允許定制包含“call service”動作、自定義事件和自定義觸發(fā)器的規(guī)則,允許開發(fā)者編程實現(xiàn)各種服務(wù).Flow 和HA 提供的這些功能非常強大,但是對終端用戶編程的能力要求高,且缺少對用戶配置的有效性檢查.
? 區(qū)分事件(event)與狀態(tài)(state)
IFTTT 的“if this then that”易被理解為通用編程中的if-then 語句,而其實際語義卻等價于事件驅(qū)動編程.Huang 等人[6]認(rèn)為:把IFTTT 隱喻成if-then 會有歧義,這種歧義會給用戶帶來困難.由此提出用事件和狀態(tài)區(qū)分觸發(fā)器:事件是瞬時信號(如“溫度降到10°C 以下”),而狀態(tài)是可隨時評價的布爾條件(如“在下雨”).Brackenbury等人[17]進(jìn)一步將動作分成事件(在特定時刻發(fā)生,如“關(guān)燈”)和狀態(tài)(一段時間內(nèi)設(shè)備的期望狀態(tài),如“燈應(yīng)亮著”)兩類.這種區(qū)分事件和狀態(tài)的TAP 看似消除了一些歧義,潛在簡化了系統(tǒng)實現(xiàn)中對TAP 規(guī)則的理解,但是研究表明:終端用戶往往很難清晰區(qū)分事件和狀態(tài)[6],且它們的組合又引出新問題.
? 事件和狀態(tài)的組合
事件和狀態(tài)在組合時有以下語義:多個狀態(tài)si的合取是另一個狀態(tài)s,僅當(dāng)每個si為真時s 為真;狀態(tài)s 與事件e 的合取是在s為真時e 同時發(fā)生的另一個事件e′;兩個事件e1和e2的合取是與e1和e2同時發(fā)生的另一個事件.然而在智能家居系統(tǒng)中,“事件同時發(fā)生”無論是理論還是實際都不太可能發(fā)生.Brackenbury 等人[17]提出了3 種多觸發(fā)器組合的時序范式:Event-Event,Event-State 和State-State,并將它們與動作組合成表1 所示的4 類TAP 規(guī)則.其中:Event-Event 時序范式引入 WITHIN 時間窗口子句來描述不能同時發(fā)生的事件,并提供AFTERWARDS 指定事件次序;Event-State 時序范式將觸發(fā)器限制為一個帶若干狀態(tài)的事件.這兩類觸發(fā)器均觸發(fā)事件型動作,也是真實智能家居系統(tǒng)主要采取的方式.State-State 觸發(fā)器范式組合多個狀態(tài)并且狀態(tài)會在一段時間內(nèi)滿足,故自然地觸發(fā)狀態(tài)動作;考慮到影響同一設(shè)備的多條規(guī)則的多個狀態(tài)可能同時為真(如控制空調(diào)的模式),故State-State→State 范式需要包含優(yōu)先級來解決沖突.此外,對于少數(shù)不能直接表示為狀態(tài)型的離散事件動作(如“記錄日志”),State-State 時序范式會觸發(fā)事件動作.
? 狀態(tài)保持性描述
Huang 等人[6]將動作分成瞬時動作(如“發(fā)郵件”)、在固定時間完成的動作(如“沖泡咖啡”)、包含改變狀態(tài)的持續(xù)性動作(如“開燈”),這給智能家居系統(tǒng)提出了描述和實現(xiàn)狀態(tài)保持特性的需求.SmartRules 提供“狀態(tài)保持”的表達(dá),可以創(chuàng)建“如果門開著有5 分鐘就通知”之類的動作.HA 提供的trigger 可以定時,雖然其action 沒有直接提供保持時長的表示方法,但是它提供的callservice 動作潛在允許開發(fā)者編寫處理狀態(tài)保持時長等服務(wù)的能力,因此也可以實現(xiàn)類似狀態(tài)保持的表達(dá).
Table 1 Four kinds of TAP rules defined by Brackenbury et al.and examples表1 Brackenbury 等人定義的4 類TAP 規(guī)則范式以及規(guī)則舉例
1.2 TAP規(guī)則的缺陷分析
用戶在編寫TAP 規(guī)則時很容易出錯,原因在于智能家居設(shè)備眾多、用戶期望的行為復(fù)雜多樣、智能家居設(shè)備之間存在大量的交互[19],單個設(shè)備會直接或間接影響到其他設(shè)備.人的行為也會影響設(shè)備狀態(tài),而人的即使看似簡單的行為也可能會引起背后復(fù)雜的設(shè)備行為;且人的行為與需求并非一成不變,在不同的場景需求下,很可能會造成對已有規(guī)則的破壞[20].由于智能家居的用戶通常缺乏編程相關(guān)的訓(xùn)練,為降低編程門檻,TAP 過分簡化了操作界面[6],從而使程序的表達(dá)能力變差,這進(jìn)一步惡化了TAP 對復(fù)雜行為的可解釋性.
Brackenbury 等人[17]通過用戶調(diào)查,總結(jié)出可能出現(xiàn)在TAP 的10 種缺陷,包括:
(1) 4 種缺陷已被發(fā)現(xiàn)且詳細(xì)討論
① 優(yōu)先級沖突(priority conflict),僅在采用State-State→State 時需要對作用于同一設(shè)備的多條規(guī)則進(jìn)行優(yōu) 先級排序,而用戶往往難以按自己的意圖正確設(shè)置規(guī)則優(yōu)先級[21].這種缺陷已被TAP 文獻(xiàn)廣泛討 論[7,13,22-24],可以通過靜態(tài)分析來檢測;
② 安全默認(rèn)偏差(secure-default bias)發(fā)生在用戶默認(rèn)系統(tǒng)處在安全狀態(tài)[21](例如夜間鎖住窗口),但廣泛部 署的Event–State 設(shè)備沒有默認(rèn)狀態(tài),Yarosh 等人詳細(xì)討論了門鎖的這種缺陷[21];
③ 非瞬時動作(extended action)源于動作發(fā)生在一段時間而不是瞬時的(如沖泡咖啡);
④ 缺少反向動作(missing reversal)發(fā)生在用戶創(chuàng)建了一條執(zhí)行某動作的規(guī)則而沒有寫撤銷該動作的規(guī)則 時,例如寫了“IF 進(jìn)客廳 THEN 開燈”但忘寫離開關(guān)燈的規(guī)則,但用戶可能認(rèn)為系統(tǒng)會自動關(guān)燈[6,21].
Huang 等人[6]詳細(xì)討論了缺陷③和缺陷④,并對系統(tǒng)接口提出改進(jìn)建議.缺陷④可以通過靜態(tài)分析檢測,但不總能被修復(fù).
(2) 3 種缺陷被提及
⑤ 無限循環(huán)(infinite loop)的原因是規(guī)則相互觸發(fā),這種缺陷在機器人終端用戶編程中常被遇到[6];
⑥ 重復(fù)觸發(fā)(repeated triggering)指用戶希望規(guī)則僅觸發(fā)一次,但卻觸發(fā)多次.這種缺陷主要出現(xiàn)在State- State 范式下因狀態(tài)觸發(fā)器持續(xù)為真導(dǎo)致規(guī)則觸發(fā)多次.Cao 等人[25]在mashup 編程工作中提及了這種 缺陷;
⑦ 不確定的時序(nondeterministic timing)是由于系統(tǒng)處理同時發(fā)生的觸發(fā)器的順序不確定而導(dǎo)致.Huang 等人[6]簡要討論了TAP 中存在的這種缺陷.
這3 種缺陷均可以通過靜態(tài)分析來檢測,但是實際系統(tǒng)無法鑒別重復(fù)觸發(fā)是否是用戶的有意行為.缺陷⑤和缺陷⑦還可以通過動態(tài)分析檢測.
(3) TAP 新增缺陷
⑧ 矛盾的動作(contradictory action)指的是長周期內(nèi)在矛盾的動作間無限循環(huán)(例如加熱和冷卻之間不斷 交替);
⑨ 時間窗錯誤(time-window fallacy)是當(dāng)用戶在編寫Event-Event 范式的規(guī)則時忘指定時間窗時導(dǎo)致;
⑩ 翻轉(zhuǎn)觸發(fā)器(flipped triggers)是因用戶難以指定觸發(fā)器中哪部分是事件哪部分是狀態(tài)而導(dǎo)致的.這種缺 陷在靜態(tài)或動態(tài)分析中都很難檢測到.
表2 總結(jié)了上述10 種缺陷的原因、引起缺陷的TAP 編程范式、缺陷檢查或修復(fù)方法.
Table 2 Causes and detection of various bugs in TAP rules表2 各種TAP 缺陷的起因與可檢測性
10 種缺陷中,第①種、第②種、第④種、第⑨種、第⑩種歸結(jié)為與用戶預(yù)期不一樣,第③種、第⑦種為時序缺陷,剩余3 種為控制流缺陷.表中第3 列的“All”表示表1 中的4 類TAP 規(guī)則都可能引起這種缺陷.從中可見:第①種和第③種這兩種缺陷僅存在于純狀態(tài)觸發(fā)器的TAP 編程中,而第⑨種、第⑩種僅存在于含事件的觸發(fā)器的TAP 編程中.Brackenbury 等人[17]對這10 種缺陷的進(jìn)一步用戶調(diào)查表明:相比Event-State,問卷參與者使用State-State 能寫得更正確,而使用Event-Event 則正確性要差些.
1.3 改進(jìn)TAP的可能渠道
現(xiàn)有的TAP 平臺尚未能充分滿足用戶需求,在實際運行中容易出現(xiàn)缺陷導(dǎo)致系統(tǒng)出錯.綜合分析現(xiàn)有智能家居系統(tǒng)及學(xué)術(shù)研究成果,以下給出了幾種改進(jìn)TAP、減少編程缺陷的渠道.
(1) TAP 編程范式
實際智能家居系統(tǒng)大都基于Event-State→Event 規(guī)則范式來實現(xiàn).相比于使用事件型觸發(fā)器進(jìn)行TAP 編程,使用純狀態(tài)觸發(fā)器更容易讓終端用戶正確表達(dá)意圖.即使使用相同的觸發(fā)器范型和動作范型,不同的TAP 規(guī)則結(jié)構(gòu)仍會影響TAP 編程的表達(dá)能力、易用性和編程缺陷.現(xiàn)有解決方案中,除了直接讓終端用戶寫TAP 規(guī)則,研究人員還提出了不同的實現(xiàn)方案,如:
? AutoTap[15]允許用戶輸入設(shè)備的安全性質(zhì)(可轉(zhuǎn)化為線性時序邏輯公式)而由系統(tǒng)合成Event-State→ Event 規(guī)則,從而減少最終規(guī)則的缺陷,但是存在合成效率較低、難以適用較多設(shè)備、安全性質(zhì)不適合表達(dá)需求細(xì)節(jié)等不足;
? Zave 等人[24]提出讓用戶對設(shè)備按不同目的(如安全性、節(jié)能等)分別描述需求特征,然后手工為特征建立狀態(tài)機,并根據(jù)它設(shè)計運行時的特征組合機制來實時控制執(zhí)行器.如何由非形式的特征描述建立FSM 以及解決特征沖突(或稱特征交互)是其中的難點,該方法目前只支持對幾種設(shè)備的人工建模且僅支持“值設(shè)置”動作.
(2) TAP 規(guī)則的檢查與修復(fù)
改進(jìn)TAP 編程范式不可能完全消除編程缺陷,TAP 平臺仍需要一些額外的工具或方法來檢查TAP 規(guī)則的有效性,并嘗試修復(fù)規(guī)則.現(xiàn)有的方法大都針對Event-State→Event 規(guī)則進(jìn)行靜態(tài)檢查(如IRuler[14],AutoTap[15],MenShen[16,22])、動態(tài)檢查(IoTGuard[19])或規(guī)則修復(fù)(AutoTap,MenShen,TrigGen[26]),僅有極個別方案是基于狀態(tài)觸發(fā)的[21,24],這很大程度上是因為實際的智能家居系統(tǒng)是按事件驅(qū)動方式來運行的.表3 從多種維度比較了已有方法,可以看出,Event-State→Event 規(guī)則的修復(fù)存在搜索修復(fù)策略低效以及在不清楚用戶意圖的情況下仍需用戶決策等局限性.而隨著設(shè)備數(shù)增多,這類規(guī)則及修復(fù)邏輯的可讀/可理解性也在下降.此外,由于網(wǎng)絡(luò)延遲/重放攻擊等,也會使基于EE 的智能家居系統(tǒng)執(zhí)行不期望的動作.Wang 等人[27]提出,通過分析日志中事件間的依賴來事后追因.
Table 3 Existing work towards bugsin smart home rules表3 關(guān)于智能家居用戶規(guī)則缺陷的相關(guān)工作
(3) 智能家居系統(tǒng)的實現(xiàn)
對TAP 規(guī)則的靜態(tài)檢測和修復(fù)可以在規(guī)則實際運行前識別出部分規(guī)則缺陷,并嘗試手工/自動修復(fù).但是如表2 第4 列所說,還有許多缺陷是靜態(tài)無法檢測,或是由于難以判斷用戶意圖從而無法確定缺陷是否存在.因此,智能家居系統(tǒng)在實現(xiàn)時需要提供:
1) 給用戶更多的提示和警告:針對那些潛在有歧義、有沖突或已做動作不會被自動撤銷等情況,系統(tǒng)要給出用戶易于理解的提示或警告;
2) 提供不易讓用戶混淆的選項供用戶選擇;
3) 提供運行時日志的記錄,需要權(quán)衡日志的存儲量與事后推理的便利性;
4) 支持和提供含義更明確的頂層trigger-action 結(jié)構(gòu),等等.
為使終端用戶易于編程,本文重點探索狀態(tài)觸發(fā)器-狀態(tài)動作的TAP 編程范式(簡稱SS 規(guī)則范式),并基于HA 構(gòu)建了支持SS 規(guī)則范式輸入的SSRules 系統(tǒng).SSRules 在不改變HA 規(guī)則執(zhí)行引擎的基礎(chǔ)上,擴展提供更易被用戶理解和掌握的規(guī)則表達(dá)方式以及對應(yīng)的規(guī)則轉(zhuǎn)譯器.雖然SS 規(guī)則范式尚不支持表達(dá)無狀態(tài)或難以抽象出狀態(tài)的事件動作,但由于這類動作所占比重小、用戶需求低,因此,SSRules 可以支持用戶的絕大多數(shù)需求.未來可以設(shè)計專門的機制,將這些無狀態(tài)的事件動作加入到SSRules 系統(tǒng)中.本節(jié)首先簡要介紹SSRules 的設(shè)計目標(biāo),然后分析HA 的關(guān)鍵特征,最后給出SSRules 總體架構(gòu)以及所引入的Entity-Capability 抽象.
2.1 設(shè)計目標(biāo)
智能家居正進(jìn)入尋常百姓家,為了讓SSRules 滿足用戶的不同需求,現(xiàn)階段至少應(yīng)圍繞如下目標(biāo)設(shè)計.
G1.易寫易改.針對用戶調(diào)查[5,6,15,17]反映的TAP 規(guī)則編寫和修改的問題,SSRules 應(yīng)提供讓無編程經(jīng)驗的終端用戶快速學(xué)習(xí)并正確使用的編程范式,方便表達(dá)所期望的智能家居系統(tǒng)性質(zhì),且在需求變化時容易修改;
G2.可管可控.SSRules 系統(tǒng)應(yīng)能提供按終端用戶的有效需求對來自不同廠商的設(shè)備實時監(jiān)測與控制,感知系統(tǒng)中動態(tài)加入和退出的管控對象,而不能只支持特定廠商的設(shè)備和僅提供極其有限的監(jiān)測能力;
G3.異常檢測.智能家居系統(tǒng)的可靠性受限于網(wǎng)絡(luò)、設(shè)備故障等不定因素,而用戶希望系統(tǒng)提供實時反饋以及對系統(tǒng)更多的控制感.因此,系統(tǒng)需要能夠幫助用戶監(jiān)視運行狀況,并將異常信息反饋給用戶;
G4.協(xié)調(diào)需求.作用于同一設(shè)備的多種需求存在沖突,是智能家居中的常見現(xiàn)象.系統(tǒng)要提供簡單的處理方式,便于用戶協(xié)調(diào)好同一設(shè)備存在沖突的多種需求.例如希望燈在夜間關(guān)閉,但是有人經(jīng)過則應(yīng)以較低亮度打開一段時間,如果遇到緊急情況(如廚房著火)則應(yīng)當(dāng)完全打開;
G5.多方信息.智能家居系統(tǒng)的功能邊界應(yīng)當(dāng)不限于家庭的物理空間.系統(tǒng)不僅要能夠處理家庭中存在的物理設(shè)備,也要能處理虛擬傳感器和虛擬的設(shè)備,如情景模式、天氣、時鐘等.
2.2 HomeAssistant(HA)
本文的研究重點為探索TAP 編程的表示及其在現(xiàn)有執(zhí)行引擎的實現(xiàn),同時提供一定的規(guī)則有效性檢查功能.因此,為更有效地實現(xiàn)G2 和G5 涉及的目標(biāo),SSRules 需要選擇成熟開源的智能家居執(zhí)行引擎來實現(xiàn)與各種(虛擬)設(shè)備的連接、實時監(jiān)控、動態(tài)感知以及自動化管理等.
在開源智能家居系統(tǒng)中,HA 是基于Python 的成熟智能家居開源系統(tǒng),能部署在任何能運行Python 3 的機器上,從樹莓派到網(wǎng)絡(luò)存儲,還可以使用Docker 部署到其他系統(tǒng)上.它主要根據(jù)automations.yaml 等配置文件實現(xiàn)集中化的智能家居設(shè)備管理,設(shè)備支持度高,具有自動化、群組化、UI 客制化等高度定制化設(shè)置;同時,其開發(fā)者數(shù)量、版本更新速度在所有開源項目中也都屬于佼佼者.因此,我們最終選取HA 作為SSRules 的執(zhí)行引擎.
? 靈活的集成方式
在HA 中,物理設(shè)備和虛擬設(shè)備均被抽象為實體,帶有狀態(tài)的實體可以與狀態(tài)對象關(guān)聯(lián).天氣、太陽角度等均為HA 預(yù)置的虛擬實體;通過用戶自定義或第三方集成,還可以實現(xiàn)如模式開關(guān)、空氣質(zhì)量、用戶位置等虛擬傳感器和動作器.實體上可以執(zhí)行的動作被抽象為服務(wù)調(diào)用,除了HA 自帶的值變化事件、服務(wù)調(diào)用事件等事件類型,第三方集成也能夠發(fā)布其他自定義的事件.采用HA 可以自然地支持目標(biāo)G5.
? 設(shè)備的動態(tài)管理
HA 接入設(shè)備的方式之一是MQTT Discovery,它提供對基于MQTT(message queuing telemetry transport)協(xié)議通信的設(shè)備的自動發(fā)現(xiàn)、配置和移除.MQTT 協(xié)議是一種基于TCP 的發(fā)布訂閱協(xié)議,在物聯(lián)網(wǎng)通信中使用較多.設(shè)備接入HA 時,每個設(shè)備只需按照HA 指定的格式配置其MQTT 通信模塊,HA 即可間接從MQTT 代理獲得配置信息并完成配置流程.若設(shè)備需要移除,則它可以更新狀態(tài)信息將自己移除,也可以由HA 根據(jù)超時設(shè)置自動移除.因此,HA 提供實現(xiàn)G2 的基礎(chǔ),SSRules 需要主動與HA 交互真正達(dá)到G2.
? 高自由度的輸入
HA 的規(guī)則輸入語言為Trigger-Condition-Action(即Event-State→Event)范式,單規(guī)則中可以含有多觸發(fā)器、多動作.動作不僅可以是與設(shè)備相關(guān)的服務(wù)調(diào)用,也可以是自定義的事件觸發(fā)和狀態(tài)值寫入、HTTP 接口調(diào)用等,自由度很高.但是HA 的自動化規(guī)則的編寫非常繁瑣,用戶難以使用其描述有優(yōu)先級的功能需求,并且用戶自行推理編寫極易遺漏或?qū)戝e.此外,由于HA 的實體狀態(tài)和服務(wù)調(diào)用之間的松耦合,HA 提供運行時異常檢查極其有限.HA 在G1,G3 和G4 方面較弱,因此,這也是SSRules 要重點解決的問題.
2.3 SSRules系統(tǒng)總體架構(gòu)
SSRules 系統(tǒng)總體架構(gòu)如圖1 所示.整個系統(tǒng)通過HA 提供的接口與智能家居設(shè)備連接,包括通過MQTT 代理連接智能家居真實設(shè)備或模擬器.系統(tǒng)由離線的轉(zhuǎn)譯器子系統(tǒng)和在線的SSRules 運行時子系統(tǒng)組成:前者提供終端用戶輸入的SS 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯,后者提供HA 抽象信息的獲取和規(guī)則執(zhí)行的有效性檢查.SSRules引入Entity-Capability 抽象(見第2.4 節(jié))來描述智能家居系統(tǒng)所能管控的設(shè)備(實體)及可管控的內(nèi)容(能力),用戶輸入的SS 規(guī)則最終被SSRules 轉(zhuǎn)化為HA 規(guī)則注入到HA 的配置文件并得以執(zhí)行.
Fig.1 Overall structure of SSRules圖1 SSRules 系統(tǒng)總體架構(gòu)
? 抽象信息獲取
SSRules 需要HA 中的實體、狀態(tài)、服務(wù)的抽象信息用于SS 規(guī)則的轉(zhuǎn)譯和異常檢測,這些信息由SSRules運行時子系統(tǒng)的抽象信息獲取模塊來提取和更新.該模塊定期從HA 更新實體信息并檢測變化情況,獲取設(shè)備的動態(tài)信息(加入或離開),生成SSRules 所需的最新實體-能力抽象信息和動作翻譯信息.
? 規(guī)則轉(zhuǎn)換流程
SSRules 的用戶交互模塊根據(jù)實體-能力抽象信息將用戶輸入規(guī)則所需的信息以用戶友好的方式呈現(xiàn)在前端界面中.用戶完成編輯后,用戶交互模塊根據(jù)用戶的輸入生成SS 規(guī)則文件.接著,SSRules 運行時系統(tǒng)會調(diào)用可離線運行的轉(zhuǎn)譯器將SS 規(guī)則轉(zhuǎn)譯成HA 規(guī)則,再將其更新到HA 的automations.yml 中.
? 異常檢測設(shè)計
當(dāng)由SS 規(guī)則翻譯得到HA 規(guī)則并開始執(zhí)行之后,規(guī)則執(zhí)行有效性檢查模塊會從HA 獲取所關(guān)心的狀態(tài)變化事件,定期獲取全部實體的狀態(tài),檢查實體狀態(tài)及其狀態(tài)變化是否符合SS 規(guī)則的描述,并將因網(wǎng)絡(luò)/設(shè)備故障等問題導(dǎo)致的設(shè)備狀態(tài)與SS 規(guī)則描述不相符等情況進(jìn)行告警以及寫入日志.
2.4 Entity-Capability抽象
一個智能家居系統(tǒng)所管理的設(shè)備可以包括真實物理設(shè)備(如空調(diào))、虛擬設(shè)備(如天氣、時鐘等),還可以是人.SSRules 系統(tǒng)使用實體-能力抽象(entity-capability abstraction)來描述智能家居系統(tǒng)中各種設(shè)備的可感知和/ 或可控制的能力,記為,ND為實體總數(shù).每個設(shè)備抽象為一個實體E(entity),每個實體由其ID e、一組能力C(capability)以及描述各能力狀態(tài)之間轉(zhuǎn)移關(guān)系的狀態(tài)機M組成,即E=(e,C,M).
? 能力
每種能力表示單個可變化的只讀或者可控屬性.表4 列出了幾種常見智能家居設(shè)備及其能力.每種能力可 表示為一個四元組(c,k,ro,J),其中:c是該能力在實體內(nèi)的唯一標(biāo)識;k表示該能力的狀態(tài)值類型,可以是二值 (binary)/多值(set)/實數(shù)(numeric)等類型之一(實數(shù)可以細(xì)分成子界類型或?qū)崝?shù)區(qū)間等,本文為簡便起見不作區(qū) 分);布爾量ro為真表示能力是只讀的、為假表示是可控的;J表示一組關(guān)聯(lián)的命令序列,其中每個元素是要執(zhí)行 的命令代號.
? 狀態(tài)機
每個實體的狀態(tài)機由該實體每種能力c 的狀態(tài)機組成:Mc=(Vc,Tc),其中,Vc是能力c 的狀態(tài)值集合,Tc是狀 態(tài)值之間的轉(zhuǎn)移函數(shù).
Table 4 Examples of entities and their capabilities表4 實體及能力舉例
在缺省的Mc中,任意兩個狀態(tài)值之間存在條件為True 的轉(zhuǎn)移(即無條件狀態(tài)轉(zhuǎn)移);若c 可控,則存在無條件 動作,它可觸發(fā)任意兩個狀態(tài)值之間的狀態(tài)轉(zhuǎn)移.SSRules 系統(tǒng)會提供初始的Mc配置文件,其中提供部分常用 設(shè)備能力及其狀態(tài)轉(zhuǎn)移描述,用戶也可以根據(jù)需要添加某個設(shè)備或者某一類設(shè)備的Mc補充信息.
根據(jù)c 的Mc抽象,可以進(jìn)一步檢測動作的執(zhí)行前提,或者判斷事件的可能性.例如,假設(shè)電扇和咖啡機的能力狀態(tài)機如圖2 所示:① 電扇的c2(風(fēng)速)只有在其c1(開關(guān))的取值為開時才可以接受改變風(fēng)速的動作;② 咖啡機的咖啡狀態(tài)僅在咖啡機的c1(開關(guān))取值為開時才能從未準(zhǔn)備好進(jìn)入準(zhǔn)備好狀態(tài).
Fig.2 The state machines for each capability of the fan and coffee machine圖2 電扇和咖啡機的能力狀態(tài)機
本節(jié)首先分析以狀態(tài)觸發(fā)器-狀態(tài)動作(SS)風(fēng)格設(shè)計SSRules 編程范式的可行性;然后給出SSRules 提供給終端用戶使用的SS 規(guī)則范式的定義,分析它在應(yīng)對表2 所列的10 種TAP 缺陷的能力;接著分析轉(zhuǎn)譯器面對的主要問題,并引入EE 中間范式作為SS 規(guī)則到HA 規(guī)則轉(zhuǎn)換的橋梁;最后介紹SS 到EE 轉(zhuǎn)譯的關(guān)鍵算法.
3.1 SS范式的引入
由第1 節(jié)可知:終端用戶不太能區(qū)分事件和狀態(tài),并且用戶使用State-State 時序范式會比使用含Event 觸發(fā)器的范式更易寫對規(guī)則.為此,我們以狀態(tài)為基礎(chǔ),通過規(guī)則分組、自動優(yōu)先級等改進(jìn)措施(詳見第3.2 節(jié))來提供“State-trigger State-action”編程范式,簡稱SS 范式.
? SS 范式的易寫易改性
SS 范式可以較為簡潔地表達(dá)用戶日常常見需求;并且和Event-State→Event 相比,SS 范式寫出的規(guī)則容易隨需求的變更和細(xì)化進(jìn)行修改.為了更清晰地表述這兩種范式的區(qū)別,表5 給出了分別用兩種范式描述夜燈開關(guān)的規(guī)則,其中,模式是HA 提供的虛擬傳感器,有回家模式和離家模式兩種取值.在SS 范式下,作用于夜燈的3條規(guī)則均作為子句按序置于“ FOR 夜燈”語句中,每個子句形如“EXPECT A [WHILE B]”,表示當(dāng)B 成立(或永真)時,期望A 中各能力為指定的值;對于同一實體的多個EXPECT,SSRules 按從前往后以第一個WHILE 條件成立的EXPECT 子句所指定的期望狀態(tài)為準(zhǔn).然而,當(dāng)用Event-State→Event 表示時,為了正確表達(dá)所列出的幾種情況的狀態(tài)保持和它們之間的轉(zhuǎn)移關(guān)系,需要寫出9 條規(guī)則來細(xì)分情況.假設(shè)用戶用SS 范式先寫了后2 條規(guī)則,運轉(zhuǎn)一段時間后他又添加第1 條保證離家模式下夜燈總是關(guān)閉的需求,在SS 范式下,這種添加是簡單的;但是若使用Event-State→Event 達(dá)到相同目的,則需要在原先第3 條~第6 條、第8 條、第9 條這6 條規(guī)則基礎(chǔ)之上新增3 條規(guī)則,并修改原先的規(guī)則細(xì)節(jié)(修改部分用粗體字表示),這樣的編寫和修改非常瑣碎、易錯.
Table 5 Example of comparing SS rules and Event-State→Event rules表5 SS 范式與Event-State→Event 范式的比較舉例
? SS 范式的局限
SS 范式能表達(dá)大多數(shù)智能家居的場景需求,但是無法表達(dá)無狀態(tài)或者難以抽象出狀態(tài)的事件和動作(如無狀態(tài)按鈕、記錄日志等).對于這類需求,目前仍需編寫Event-State→Event 規(guī)則.因此,SSRules 將SS 范式轉(zhuǎn)譯為Event-State→Event,并允許兩種范式共存.未來可以擴展降低這類需求編程難度的具體范式.
3.2 SS范式的定義
表6 的左部列出了SSRules 系統(tǒng)支持的SS 范式的抽象語法,其中:FOR 語句集結(jié)同一動作實體的所有規(guī)則,且約定組內(nèi)靠前的規(guī)則優(yōu)先級更高;每條規(guī)則(ssrule)包含在WHILE 子句指定的條件成立時,對該實體全部或部分能力的期望狀態(tài);多條規(guī)則按從前到后的次序、以第1 條滿足WHILE 條件的規(guī)則中的EXPECT 子句來設(shè)置期望的實體能力狀態(tài);一般地,無 WHILE 子句的規(guī)則放在最后作為安全默認(rèn).Condition 中的“entityID.capName op value”,“historyOp timeperiod entityID.capName value”分別表示當(dāng)前狀態(tài)和歷史狀態(tài)型原子判斷,其中,歷史狀態(tài)運算符historyOp 的4 種可能取值的含義舉例如下.
? “WITHIN 5 分鐘電扇.開關(guān)關(guān)”表示電扇的開關(guān)在5 分鐘內(nèi)曾經(jīng)處于關(guān)閉狀態(tài),則該原子判斷為真;
? “!WITHIN 5 分鐘電扇.開關(guān)關(guān)”表示電扇的開關(guān)在5 分鐘內(nèi)不曾處于關(guān)閉狀態(tài),則該原子判斷為真;
? “STAY 5 分鐘電扇.開關(guān)開”表示電扇的開關(guān)在5 分鐘內(nèi)持續(xù)處于開啟狀態(tài),則該原子判斷為真;
? “!STAY 5 分鐘電扇.開關(guān)關(guān)”表示電扇的開關(guān)在5 分鐘內(nèi)未一直處于開啟狀態(tài),則該原子判斷為真.
Table 6 Abstract syntax of paradigms of SS rules and EE rules used in SSRules表6 SSRules 系統(tǒng)使用的SS 范式和EE 范式的抽象語法
3.3 SS范式的缺陷避免能力分析
SS 范式天然地排除了表2 中所列的缺陷⑨、缺陷⑩這兩種缺陷.對于在使用State-State 時序范式時可能存在的缺陷①~缺陷⑧這8 種缺陷,SS 范式的表示機制能完全避免缺陷①優(yōu)先級沖突;SS 范式的表示及轉(zhuǎn)譯機制能部分解決或消除缺陷②安全默認(rèn)偏差、缺陷③非瞬時動作、缺陷⑥重復(fù)觸發(fā),其附帶效果可以輔助改善缺陷④缺少反向動作;對于缺陷⑤無限循環(huán)、缺陷⑦不確定時序等缺陷的檢測,可以通過模型檢查等方法在規(guī)則轉(zhuǎn)譯之前避免;由于難以提供通用的鑒別何謂矛盾的機制,因而SSRules 不能解決缺陷⑧矛盾的動作.下面分別討論SS 范式應(yīng)對缺陷①~缺陷③和缺陷⑥的措施.
(1) “按動作實體將規(guī)則分組、組內(nèi)規(guī)則有序”可完全避免缺陷①優(yōu)先級沖突
用戶只需移動規(guī)則在組內(nèi)的相對位置,免除顯式設(shè)置優(yōu)先級數(shù)值的困難.由于同一動作實體的各規(guī)則優(yōu)先級不同,故無缺陷①(示例見3.1 節(jié)).
(2) “將配置的安全默認(rèn)規(guī)則自動作為動作實體的最低優(yōu)先級規(guī)則”可輔助消除缺陷②安全默認(rèn)偏差
SSRules 提供可配的安全默認(rèn)設(shè)置文件,其中的條目形如“實體/實體類ssrule”可描述指定實體或?qū)嶓w類的默認(rèn)期望狀態(tài),SSRules 會自動將其追加到相應(yīng)實體的規(guī)則集尾部,作為最低優(yōu)先級規(guī)則.例如針對門鎖可以配置默認(rèn)安全規(guī)則“EXPECT (狀態(tài),鎖定)”,則用戶只需描述其他需求,如:
FOR 門鎖 EXPECT (狀態(tài),未鎖定) WHILE 人體傳感器.狀態(tài)==激活 [AND 其他安全條件]
而SSRules 會自動在尾部追加“EXPECT (狀態(tài),鎖定)”.只要人體傳感器不再激活,SSRules 就會按最后一條無條件子句的期望狀態(tài)將門鎖鎖定.這種做法消除缺陷②的前提是要正確配置安全默認(rèn)文件.
如果用戶希望在人體傳感器激活后2 分鐘內(nèi)均保持門鎖解鎖,可使用SS 范式提供的歷史狀態(tài)判斷:
FOR 門鎖 EXPECT (狀態(tài),未鎖定) WHILE WITHIN 2 分鐘人體傳感器.狀態(tài)激活 [AND 其他安全條件]
(3) “通過避免用戶直接編寫動作”可避免缺陷③非瞬時動作和缺陷⑥重復(fù)觸發(fā)
在SSRules 中,狀態(tài)轉(zhuǎn)移所需要的動作的執(zhí)行前提被描述在實體-能力抽象信息中,用戶只能選擇期望的狀態(tài),而無法寫出有缺陷的程序造成對非瞬時動作的多次觸發(fā)動作而進(jìn)入不期望的狀態(tài).例如:針對沖泡咖啡這樣的非瞬時動作,如果主人希望每天7:00 讓咖啡機工作,且咖啡機工作完成后自動關(guān)閉,7:00~7:20 之外的時間不開啟咖啡機,則用SS 范式編寫的規(guī)則為:
FOR 咖啡機
EXPECT (開關(guān),開) WHILE 時鐘.時間>7:00 AND 時鐘.時間<7:20 AND 咖啡機.咖啡狀態(tài)==未準(zhǔn)備好
EXPECT (開關(guān),關(guān))
當(dāng)咖啡機開啟后,即使咖啡未準(zhǔn)備好,SSRules 轉(zhuǎn)譯后的HA 規(guī)則也保證不會再出現(xiàn)開啟動作.而用戶倘若用State-State→Event 范式,容易寫出如下有缺陷的規(guī)則,造成咖啡機多次啟動:
IF 咖啡未準(zhǔn)備好 AND 時間處于7:00~7:20 之間 THEN 啟動咖啡機
對于重復(fù)觸發(fā)缺陷,能夠用SS 范式表達(dá)的規(guī)則可以用上述類似的機制來避免;而不能夠用SS 范式表達(dá)的規(guī)則,仍需要使用Event-State→Event 或者Event-Event→Event 范式來寫(未來將對此提供更直觀的編程方式).
3.4 轉(zhuǎn)譯器面對的問題及EE中間范式的引入
? 轉(zhuǎn)譯器面對的問題
如果要在一個僅支持Event-State→Event 范式的智能家居系統(tǒng)上實現(xiàn)對SS 范式規(guī)則的支持,需要將智能家居系統(tǒng)狀態(tài)之間的轉(zhuǎn)移和狀態(tài)轉(zhuǎn)移帶來的新的狀態(tài)設(shè)定與智能家居系統(tǒng)所支持的事件和動作關(guān)聯(lián)起來,并且要盡可能避免重復(fù)觸發(fā)、非瞬時動作等缺陷.這一翻譯過程應(yīng)該對用戶不可見,是由系統(tǒng)自動完成的.此外,為了從翻譯的主要算法中排除HA 規(guī)則描述的瑣碎細(xì)節(jié),以及讓算法一般化以支持到其他平臺的移植,SSRules 引入了EE 中間范式(基于Event-State→Event).從而:轉(zhuǎn)譯器的第1 階段,SS→EE 的翻譯可以避開HA 的語法及實現(xiàn)細(xì)節(jié),重點是基于同一套實體-能力抽象將SS 范式表示的功能需求轉(zhuǎn)化為EE 范式所表示的具體做法;而第2 階段,EE→HA 的翻譯則只需從較為抽象的EE 規(guī)則根據(jù)HA 的事件/條件描述方式、動作對應(yīng)表,生成HA 所需的規(guī)則細(xì)節(jié)即可.
? EE 中間范式
表6 的右部列出了SSRules 系統(tǒng)轉(zhuǎn)譯中使用的EE 中間范式的抽象語法,其主要特點為:一條規(guī)則可以含有多個觸發(fā)事件(event)、條件過濾(condition)和多個按順序執(zhí)行的動作(eeAction).event 包括狀態(tài)值變化事件“entityID.capName FROM range TO range”和狀態(tài)保持事件“entityID.capName STAYON value REACH timeperiod”:前者表示給定實體能力的取值從一個值集變遷到另一個值集,后者表示指定的實體能力保持給定值value 的時間長達(dá)timeperiod 時觸發(fā)該事件.目前,SSRules 僅對二值類型的能力提供狀態(tài)保持事件.EE 范式中條件過濾condition 的定義與SS 范式一樣.
? EE 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯
EE 規(guī)則到HA 規(guī)則的翻譯是一一對應(yīng)的,EE 規(guī)則的狀態(tài)值變化事件可以對應(yīng)到HA 的state_changed 事件和在HA 規(guī)則的condition 中對事件數(shù)據(jù)中的old_state 和new_state 的限制條件.EE 規(guī)則中的狀態(tài)保持事件可以轉(zhuǎn)譯為在HA 中的延時執(zhí)行和自定義事件觸發(fā).EE 規(guī)則中的條件表達(dá)式可以對應(yīng)到HA 條件表達(dá)式中的相同樹形結(jié)構(gòu).EE 規(guī)則中,實體能力的取值對應(yīng)到HA 規(guī)則中的狀態(tài)對象state 或者狀態(tài)對象attribute 中的附加狀態(tài);EE 規(guī)則中,對實體能力的歷史狀態(tài)判斷被對應(yīng)到HA 規(guī)則中的自定義狀態(tài)對象取值判斷;EE 規(guī)則中的一個或多個動作被單個或組合對應(yīng)到HA 中無參或帶參的服務(wù)調(diào)用.
3.5 SS規(guī)則集與EE規(guī)則集的符號表示與一些定義
為了方便后文的說明和理解,我們引入表7 中的符號以及幾個基本概念,這些符號和表6 定義的語法結(jié)構(gòu) 一一對應(yīng).例如:GS對應(yīng)于語法定義中的一個ssrulesGroup,RS對應(yīng)于一個ssrule,RS中的C和X分別對應(yīng)于 WHILE 子句中的條件表達(dá)式和EXPECT 子句中的期望狀態(tài)組.wt 和st 分別表示“WITHIN”和“STAY”.
Table 7 Symbolic representation of SS ruleset and EE ruleset表7 SS 規(guī)則集合和EE 規(guī)則集合的符號表示
對于一個由ND個實體組成的智能家居系統(tǒng),每個由三元組(e,C,M)描述.在某個時刻下,W的系統(tǒng)狀態(tài)記為σ,它是各實體的各能力到狀態(tài)值的映射,即σ(e,c)表示實體e的能力c 在該時刻的狀態(tài)值.不論是SS 范式的程序GS,還是EE 范式的程序RE,都是對系統(tǒng)狀態(tài)變遷的描述;而轉(zhuǎn)譯的目標(biāo)是由GS得到RE,使得GS與RE滿足一致性.在定義一致性之前,我們先定義系統(tǒng)抽象狀態(tài)ω,然后定義SS 規(guī)則與系統(tǒng)抽象狀態(tài)ω的關(guān) 系,包括規(guī)則在ω下是否激活、規(guī)則是否與ω兼容.
定義1(系統(tǒng)抽象狀態(tài)).對于規(guī)則引擎來說,系統(tǒng)當(dāng)前狀態(tài)σ、當(dāng)前時刻τnow以及狀態(tài)變化軌跡T可抽象為一個三元組ω=(σ,τnow,T),稱之為系統(tǒng)抽象狀態(tài).其中,T=((e1,c1,v1,τ1),,…,(en,cn,vn,τn)),(ei,ci,vi,τi)表示實體ei的能力ci在τi時刻變?yōu)関i(i∈{1,…,n}),它只記錄狀態(tài)值發(fā)生變化的特定實體的特定能力及其新狀態(tài).狀態(tài)變化可能由外 部事件引起(如用戶交互、環(huán)境變化),也可能由GS或RE執(zhí)行動作序列引起.每當(dāng)發(fā)生狀態(tài)變遷時,都相當(dāng)于T更新為,其中,τn+1為狀態(tài)變遷發(fā)生時的τnow.
定義2(規(guī)則在系統(tǒng)抽象狀態(tài)ω下激活).假設(shè)GS=(e,RS)為某動作實體e的SS 規(guī)則組,表示RS中期望狀態(tài)組均為X的規(guī)則子集,當(dāng)前的系統(tǒng)抽象狀態(tài)為ω.稱期望狀態(tài)組相同的一組規(guī)則SXR 在ω下激活,是指該組內(nèi)任 意一條規(guī)則RS激活;而規(guī)則RS在ω下激活,是指在該規(guī)則所在的規(guī)則組GS內(nèi),其前面的規(guī)則的條件(對應(yīng)WHILE子句,即C)在ω下都未滿足,而該規(guī)則的條件RS.C滿足.
定義3(規(guī)則與系統(tǒng)抽象狀態(tài)ω兼容).規(guī)則RS與系統(tǒng)抽象狀態(tài)ω不兼容,是指在ω下RS激活且RS.X尚不成立;而RS與ω兼容,是指在ω下RS未激活或者RS.X已成立;一組規(guī)則與ω兼容,是指組內(nèi)每條規(guī)則與ω都是兼容的;一 組規(guī)則與ω不兼容,是指組內(nèi)存在與ω不兼容的規(guī)則.
實際的規(guī)則引擎提供的時間戳的精度是有限的.假設(shè)系統(tǒng)抽象狀態(tài)ω中的時間戳都有最小時間單位(例如1秒),τnow以最小時間單位離散地更新.那么,對于規(guī)則集合執(zhí)行方式的假設(shè)如下.
? SS 規(guī)則執(zhí)行假設(shè).假設(shè)無時序缺陷的規(guī)則組GS的執(zhí)行方式為:每當(dāng)發(fā)生狀態(tài)變化,或者τnow變?yōu)樾轮抵?判斷GS中是否存在與最新的ω不兼容的規(guī)則.如果存在這樣的規(guī)則RS,說明其對應(yīng)實體e不滿足RS的期望狀態(tài)組X,于是計算e上的需要執(zhí)行的動作序列A,使得A執(zhí)行后實體e的狀態(tài)符合X;
? EE 規(guī)則執(zhí)行假設(shè).假設(shè)無時序缺陷的規(guī)則組RE的執(zhí)行的方式為:設(shè)RE中的所有觸發(fā)事件可分為狀態(tài) 變化事件EI和狀態(tài)保持事件EH這兩種類型,每當(dāng)出現(xiàn)與EI相符的狀態(tài)變遷,或者每當(dāng)τnow的更新觸發(fā)了EH中的某個狀態(tài)保持事件后,檢查與觸發(fā)事件相符的各條規(guī)則.如果存在RE,RS.C在ω下成立,則執(zhí)行 RE.A.
定義4(SS 與EE 的一致性).稱GS與RE一致是指:對于無時序缺陷的GS,RE,在上述規(guī)則執(zhí)行假設(shè)下(且不存在超時、執(zhí)行失敗、規(guī)則重疊執(zhí)行的情形),從與GS兼容的任意系統(tǒng)抽象狀態(tài)ω開始,對于同樣的、同時刻的、一次發(fā)生一個事件的外部事件序列,GS所產(chǎn)生的狀態(tài)變遷序列和RE所產(chǎn)生的狀態(tài)變遷序列一致.
與GS一致的RE不唯一,原因在于:① RE中不會被執(zhí)行的規(guī)則不影響一致性;② 一個條件較弱的EE 規(guī)則(如一條規(guī)則,條件.C為時鐘.狀態(tài)==白天)可等價于多個條件更強的EE 規(guī)則(如等價于規(guī)則和,條件.C和.C分別為“時鐘.狀態(tài)==白天 AND 模式.狀態(tài)==回家模式”和“時鐘.狀態(tài)==白天 AND 模式.狀態(tài)==離家模式”);③ 一條EE 規(guī)則RE還可以等價于m條EE 規(guī)則,滿足.E ;④ 邏輯表達(dá)式 有多種等價表述.
3.6 SS規(guī)則到EE規(guī)則的轉(zhuǎn)譯
圖3 詳細(xì)說明了SS 規(guī)則到EE 規(guī)則的轉(zhuǎn)譯算法實現(xiàn),其中:圖3(a)中的算法1 是總控算法;圖3(b)是相應(yīng)的 流程圖,轉(zhuǎn)譯器的輸入分別是左上角的實體-能力抽象信息W和右上角的SS 規(guī)則集合GS,輸出是與輸入SS 規(guī)則集對應(yīng)的EE 規(guī)則集RE(右下角).
Fig.3 Algorithm and flowchart of translation from SS rules to EE rules圖3 SS 規(guī)則到EE 規(guī)則轉(zhuǎn)譯算法與流程圖
轉(zhuǎn)譯的具體流程為:
? SS 規(guī)則集解析器首先會解析用戶輸入的GS,并將解析結(jié)果傳給動作序列信息生成模塊;
? 然后,動作序列信息生成模塊會將同一動作實體e的SS 規(guī)則序列GS=(e,RS)按照EXPECT 子句作用的期望狀態(tài)組分類,期望狀態(tài)組X相同的SS 規(guī)則組中的多條規(guī)則會放在一起處理:一方面,調(diào)用ConditionalActionsPairs(e,X,W)(見算法2),計算實體e上所有可能的動作序列Aj和每種動作序列的執(zhí)行前提Cj,得到二元組集合PairsX={(Cj,Aj) |j∈{1,n}};另一方面,求出與規(guī)則組不兼容的條件ΨX(見算法1 第5 行),這是事件發(fā)生后、動作執(zhí)行前系統(tǒng)抽象狀態(tài)所應(yīng)滿足的條件;
? 接下來,事件篩選模塊首先調(diào)用CandidateEvents(ΨX,W)(見算法3),根據(jù)ΨX生成一組候選事件E(這些事件可能對ΨX的成立與否有影響);然后,對E中的每個事件E調(diào)用ShouldRejectEvent(E,ΨX,W)(見算法4),依據(jù)缺省的事件篩選策略Pdefault判斷該事件是否要排除掉,即:若E發(fā)生后ΨX不成立,則需將E排除;
在轉(zhuǎn)譯過程中,有多個環(huán)節(jié)需要與Z3 交互:在轉(zhuǎn)譯開始之前,轉(zhuǎn)譯器會根據(jù)實體-能力抽象構(gòu)建Z3 數(shù)據(jù)類型和Z3 常量,并將對應(yīng)關(guān)系填入Z3-Python 數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換模塊中的Z3 常量映射表;在轉(zhuǎn)譯過程中,事件篩選模塊和EE 中間表示生成模塊通過Z3 判定事件的可滿足性;規(guī)則合并模塊通過Z3 判斷等價的條件部分,合并觸發(fā)事件;可讀性化簡模塊通過Z3 進(jìn)行表達(dá)式化簡以減少條件表達(dá)式長度.
下面結(jié)合算法2~算法5 詳細(xì)介紹動作序列信息生成、事件篩選以及EE 中間表示生成這3 個關(guān)鍵模塊.
算法2.“執(zhí)行前提-動作序列”對集合的生成(ConditionalActionsPairs).
輸入:實體e,期望狀態(tài)組X,系統(tǒng)實體-能力抽象W;
輸出:結(jié)構(gòu)如{(C1,A1),…,(Cn,An)}的Pairs,表示實體e 滿足Ci時要達(dá)到X需執(zhí)行Ai.
? 動作序列信息生成模塊
該模塊會針對期望狀態(tài)組X相同的SS 規(guī)則組,調(diào)用算法2 產(chǎn)生可能的動作序列及其執(zhí)行前提集合PairsX={(Cj,Aj) |j∈{1,n}},并求出與不兼容的條件ΨX(見算法1 第5 行).算法2 的第2 行指出,X投影得到的能力集合XC 中的每個能力都必須是可控的.如第2.4 節(jié)所述,可控能力c 的狀態(tài)機Mc=(Vc,Tc)中的轉(zhuǎn)移函數(shù),每個狀態(tài)轉(zhuǎn)移帶有條件C以及要執(zhí)行的命令J,C中可能會涉及其他實體能力.考慮到實際需求以及處理上的簡便,假設(shè)XC 中各能力的狀態(tài)轉(zhuǎn)移條件C中依賴的其他能力遵循部分序關(guān)系,算法2 的第3行調(diào)用Reorder 函數(shù)將XC 中的能力按這種序關(guān)系重排得到,這樣在第8 行就可以嘗試按此順序依次檢查動作轉(zhuǎn)移的可行性.另外,對于中的能力ci,其狀態(tài)值域可能是無限的實數(shù),而是有限的,故第5 行的SplitRangeByAction 函數(shù)會檢查中到達(dá)期望值vi的各個狀態(tài)轉(zhuǎn)移動作J和轉(zhuǎn)移條件C,將J,C相同的狀態(tài)轉(zhuǎn)移的起始狀態(tài)涉及的各狀態(tài)值劃分到同一個子集,從而形成的有限子集劃分Setsi,進(jìn)而可能減少第7 行要處理的初始狀態(tài)情形的數(shù)目,也能夠減少后續(xù)規(guī)則合并的運算次數(shù).
下面結(jié)合圖4 的例子來解釋.該例子的動作實體為“電扇”,有3 條SS 規(guī)則.這些規(guī)則按期望狀態(tài)組X是否相同分成兩組.以組為例,根據(jù)該組的X2“(開關(guān),開)(風(fēng)速,低)”和圖2 電扇的狀態(tài)機,按照算法2 求出到達(dá)X2的所有執(zhí)行前提-動作序列對(圖4 左下方的4 種動作序列).另一方面,該模塊也要輸出不兼容的條件用于稍后的事件篩選,=模式.狀態(tài)==回家模式 AND 溫濕度傳感器.溫度 >28°C AND (電扇.開關(guān)!=開OR 電扇.風(fēng)速!=低).
Fig.4 Generating sequences of commands information圖4 動作序列信息生成
? 事件篩選模塊
該模塊先使用算法3 生成候選事件,接著進(jìn)一步使用算法4,根據(jù)系統(tǒng)可能的狀態(tài)變遷對事件進(jìn)行篩選.算法3 主要根據(jù)一個執(zhí)行前要滿足的條件C生成候選事件集,旨在以較低運算成本快速得到較小的待篩選事件集.其中:第2 行分別獲取C中出現(xiàn)的實體能力集合ECs以及原子條件集合Catom,原子條件有當(dāng)前狀態(tài)判斷(e,c,O,v)和歷史狀態(tài)判斷(e,c,Oh,t,v)這兩種形式(如表7);第4 行的SplitRangeByCond 則是根據(jù)Catom對實體E的能力 c 的狀態(tài)值域Vc進(jìn)行劃分,將對所有原子條件的判斷影響一致的狀態(tài)取值劃分到同一個子集,從而將實數(shù)類型的事件轉(zhuǎn)移轉(zhuǎn)化為了有限情形;第5 行~第7 行分別產(chǎn)生狀態(tài)變化事件El和狀態(tài)保持事件EH,能夠涵蓋C中出現(xiàn)的原子條件取值變化的情形.對于歷史狀態(tài)原子條件(e,c,Oh,t,v),由于只支持二值類型的能力c,在固定e,c,t下,Oh和v最多有8 種組合,我們?yōu)橹磛的兩種取值產(chǎn)生2 種狀態(tài)保持事件,忽略O(shè)h;而被忽略的Oh仍在C中,傳 遞到后續(xù)由算法5 產(chǎn)生的EE 規(guī)則RE=(E,C,A)中.這種狀態(tài)保持事件EH能在狀態(tài)遷移中快速知道實體能力保 持狀態(tài)的時長,再結(jié)合C中的Oh進(jìn)行狀態(tài)保持的可滿足性檢查.
算法3.候選事件生成算法(CandidateEvents).
算法4.事件排除判定算法(ShouldRejectEvent).
算法5.同一動作序列的EE 規(guī)則生成(SameActionsRules).
算法4 旨在判斷事件E可否發(fā)生并在發(fā)生后使得Ψ(不兼容的條件)為真(進(jìn)而導(dǎo)致Ψ對應(yīng)的某個動作序列的執(zhí)行),需要根據(jù)篩選策略P做關(guān)于系統(tǒng)抽象狀態(tài)的可滿足性判定.篩選策略從保守到激進(jìn)有多種策略:激進(jìn) 的策略需要對事件發(fā)生之前的系統(tǒng)狀態(tài)做出更強的假設(shè),而保守的策略只需要相對較弱、能夠更快判定的假 設(shè).本文提出的默認(rèn)策略Pdefault為:事件發(fā)生前Ψ為假(兼容),事件發(fā)生后Ψ為真(不兼容),且事件發(fā)生前 后Vs→Vd的事件轉(zhuǎn)移條件CE成立,則該事件不會被排除.
Fig.5 Relation between current event filtering strategy and state transition圖5 當(dāng)前使用的事件篩選策略與狀態(tài)轉(zhuǎn)移的關(guān)系
? EE 中間表示生成模塊
該模塊調(diào)用算法5 生成EE 規(guī)則.以上一步驟篩選輸出的事件E=(模式,狀態(tài),{離家模式},{回家模式})、規(guī) 則組的不兼容條件為例,對于圖4 左下方中的4 個執(zhí)行前提-動作序列對,都要判斷執(zhí)行前提是否可能 滿足并生成規(guī)則.這里以4 對中的左上一對為例,由算法5 的第5 行得到的條件:“回家模式=回家模式 AND 溫濕度傳感器.溫度>28°C AND (電扇.開關(guān)!=開 OR 電扇.風(fēng)速!=低) AND (電扇.開關(guān)!=開 AND 電扇.風(fēng)速!=低)”作為動作執(zhí)行的完整前提條件,同時也應(yīng)當(dāng)是E發(fā)生后為真的條件,結(jié)合事件發(fā)生前應(yīng)當(dāng)為真的條件!Ψ,得到關(guān)于系統(tǒng)狀態(tài)的斷言并判定是可滿足的,因此生成一條規(guī)則:
IF 模式.狀態(tài) FROM {離家模式} TO {回家模式} WHILE 溫濕度傳感器.溫度>28°C AND
電扇.開關(guān)!=開 AND 電扇.風(fēng)速!=低 THEN 電扇.開關(guān) 打開,電扇.風(fēng)速 設(shè)定 低.
算法4 雖然和這里的算法5 都需要對一組系統(tǒng)狀態(tài)的斷言做可滿足性求解,但是算法4 不考慮動作序列的 執(zhí)行前提,其篩選結(jié)果能夠被同一X的多個動作序列復(fù)用;且能夠通過算法4 篩選的只有較少數(shù)量事件,這些事 件至少能夠與一個動作序列組合成為規(guī)則.算法4 的存在,減少了轉(zhuǎn)譯過程中總的可滿足性判定的次數(shù).若直接將候選事件集合與多種動作序列的組合輸入算法5,可能需要較多次數(shù)的不必要的求解.
為了驗證SSRules 的系統(tǒng)設(shè)計的有效性,基于Python 開發(fā)了SSRules 運行時子系統(tǒng)和離線轉(zhuǎn)譯器;基于Javascript 開發(fā)了SSRules 前端用戶交互模塊,方便終端用戶設(shè)置SS 規(guī)則(如圖6 左上方);同時,結(jié)合已有用戶調(diào)查[15]構(gòu)建智能家居使用情景,在這些場景下,就SSRules 系統(tǒng)運行情況和規(guī)則轉(zhuǎn)譯效果進(jìn)行評估和討論.
4.1 智能家居實驗場景搭建
為了能夠評估SSRules,需要將一些設(shè)備連接到HA,并讓設(shè)備和環(huán)境產(chǎn)生足夠多的狀態(tài)轉(zhuǎn)移,以覆蓋各種可能的使用情形.但是,使用真實設(shè)備無法在短時間得到這樣的測試場景并且調(diào)試不便.為此,我們基于Unity 游戲引擎開發(fā)了一個能接入HA 的智能家居模擬器HA-Simulator(其界面如圖6 下方).利用HA-Simulator 可以將時間加速,以較高的速度發(fā)生系統(tǒng)的狀態(tài)變化,并對溫濕度/煙霧濃度等環(huán)境因素合理建模.這使得在短時間內(nèi)測試大量的智能家居系統(tǒng)狀態(tài)變遷并驗證SSRules 成為可能.
在HA-Simulator 中模擬了12 種智能家居設(shè)備,布局和類型如圖6 右上方所示,這些設(shè)備通過HA 的MQTT Discovery 集成方式接入HA.此外,在HA 中以自定義方式提供模式、天氣和時鐘這3 種虛擬設(shè)備.在模擬器中,同一房間內(nèi)的設(shè)備受同一組環(huán)境變量(溫度、濕度、煙霧濃度)的影響.模擬器可以設(shè)置環(huán)境變量改變的速度,進(jìn)而間接改變虛擬傳感器的取值;同時,模擬器中的設(shè)備可以被手動調(diào)節(jié)或者由模糊測試程序隨機改變.
Fig.6 SSRules user interface,Smart home configuration and HA-simulator圖6 SSRules 用戶交互界面與智能家居場景配置和模擬器示意圖
4.2 實驗結(jié)果分析
? SS→HA 翻譯對比
首先參考以往用戶調(diào)查[15]中用戶的智能家居需求,構(gòu)造了10 組SS 規(guī)則作為測試集,其中:編號為1~6 的規(guī)則組不含歷史狀態(tài),編號為T1~T4 的規(guī)則組含有歷史狀態(tài).每一組規(guī)則至少有一個動作實體(設(shè)備),規(guī)則中會引用多個相關(guān)實體的狀態(tài).另外,規(guī)則組6、規(guī)則組T3、規(guī)則組T4 含有多個動作實體.按照當(dāng)前的事件篩選策略,翻譯前后的規(guī)則條數(shù)比較見表8.最終生成的HA 規(guī)則條數(shù)均多于SS 規(guī)則條數(shù),比例為2 倍~4 倍.
? HA 規(guī)則運行覆蓋率
在由SS 轉(zhuǎn)譯得到HA 規(guī)則之后,每一組HA 規(guī)則均在模擬器上運行20 分鐘.除第1 組規(guī)則(包含空調(diào)與溫濕度傳感器)和第3 組規(guī)則(包含排氣扇以及其他4 個相關(guān)實體)之外,其余組的HA 規(guī)則均全部被執(zhí)行過.這說明SS→HA 轉(zhuǎn)譯器為其余8 組規(guī)則產(chǎn)生的HA 規(guī)則集中沒有多余的規(guī)則,當(dāng)前的事件篩選策略對于多數(shù)測試樣例是比較合理的.對于含有多余規(guī)則的情形,而第1 組的4 條SS 規(guī)則為:
FOR 客廳空調(diào)
EXPECT (模式,制冷)(溫度,18°C) WHILE 客廳溫濕度傳感器.溫度>28°C
EXPECT (模式,制熱)(溫度,20°C) WHILE 客廳溫濕度傳感器.溫度<10°C
EXPECT (模式,干燥) WHILE 客廳空調(diào).模式!=制熱 AND 客廳空調(diào).模式!=制冷 AND 客廳溫濕度傳感器.濕度>65% EXPECT (模式,關(guān)) WHILE 客廳溫濕度傳感器.溫度<22°C AND 客廳溫濕度傳感器.溫度>14°C 而在轉(zhuǎn)譯出的13 條HA 規(guī)則中,沒有被執(zhí)行過的(可能是多余的)一條HA 規(guī)則用EE 范式表達(dá)為:
IF 客廳溫濕度傳感器.溫度 FROM (-30°C,10°C)∪(28°C,70°C) TO [10°C,28°C] WHILE
客廳空調(diào).模式!=制冷 AND 客廳空調(diào).模式!=制熱 AND 客廳空調(diào).模式!=干燥
AND 客廳溫濕度傳感器.濕度>65% THEN 客廳空調(diào).模式設(shè)定干燥
Table 8 Comparison of SS and HA rules and test results表8 SS→HA 翻譯對比和測試運行
原因在于:當(dāng)前的篩選策略沒有假設(shè)系統(tǒng)狀態(tài)在事件發(fā)生之前的瞬間與整個規(guī)則組GS的描述相符,而僅僅假設(shè)系統(tǒng)狀態(tài)與第3 條SS 規(guī)則的描述是兼容的(即第3 條規(guī)則未激活或者其期望狀態(tài)已滿足).但是在測試運行中,當(dāng)溫度低于10°C 或者高于28°C 時,系統(tǒng)狀態(tài)持續(xù)與GS的描述相符,空調(diào)模式一定是制熱(第2 條SS 規(guī)則激活)或者制冷(第1 條SS 規(guī)則激活),所以該條EE 規(guī)則是多余的,通過使用更激進(jìn)的事件篩選策略可將其消除.
? HA 規(guī)則運行異常檢測
表8 的后3 列分別是在20 分鐘的隨機測試下,各組的HA 規(guī)則的執(zhí)行次數(shù)、異常檢測模塊發(fā)現(xiàn)的異常次數(shù)(系統(tǒng)狀態(tài)不滿足動作實體的SS 規(guī)則集合中激活的那一條SS 規(guī)則的期望狀態(tài))與總檢測次數(shù)之比、是否存在連續(xù)兩次檢測到異常的情況.各組總的規(guī)則執(zhí)行次數(shù)相差不大.異常檢測模塊目前以定時輪詢方式實現(xiàn),在20分鐘內(nèi)進(jìn)行了1 200 次異常檢查,未發(fā)現(xiàn)連續(xù)出現(xiàn)異常的情形.對于單次檢測出現(xiàn)異常的情況,經(jīng)過查看記錄的狀態(tài)日志和HA 規(guī)則的執(zhí)行序列,這些異常均因網(wǎng)絡(luò)延遲(動作執(zhí)行不及時)造成.
智能家居目前在市場上受到了廣泛歡迎,越來越多的家庭配置了智能家居的設(shè)備.智能家居最吸引人的功能之一就是以應(yīng)用程序的形式支持自定義自動化.但是由于用戶未經(jīng)過專業(yè)的培訓(xùn),導(dǎo)致其自定義的規(guī)則存在一定的缺陷,甚至無法定制規(guī)則,這引起了人們對物聯(lián)網(wǎng)增強生活的風(fēng)險的擔(dān)憂.這些風(fēng)險遠(yuǎn)非僅僅是學(xué)術(shù)上的,更緊迫的是對用戶的生命財產(chǎn)的威脅.Triger-Action 編程(TAP)是一種流行的終端用戶編程方式,可以讓用戶實現(xiàn)其智能設(shè)備和云服務(wù)的交互.然而,用戶有時并不能通過TAP 正確表達(dá)自己的意圖并實現(xiàn)相應(yīng)的功能.隨著此類系統(tǒng)部署在越來越復(fù)雜的智慧家居場景中,用戶必須能夠識別編程錯誤并解決.
為了給終端用戶提供更高效的服務(wù),首先需要理解用戶編程出現(xiàn)錯誤和規(guī)則沖突的原因.Huang 等人[6]認(rèn)為,現(xiàn)有TAP 編程系統(tǒng)(如IFTTT)的過分簡化限制了程序的表達(dá)能力.提出了改進(jìn)IFTTT 界面的建議,以減輕因心理模型不正確而引起的問題.Corno 等人[28]認(rèn)為:現(xiàn)有的TAP 接口界面暴露了太多功能,并迫使用戶在眾多混亂的網(wǎng)格菜單中進(jìn)行搜索,導(dǎo)致用戶無法得到原本需要的功能.為此,作者提出了EUDoptimizer,旨在以交互方式協(xié)助終端用戶使用循環(huán)中的優(yōu)化器來組合 IF-THEN 規(guī)則,減少了編寫Triger-Action 規(guī)則所需的工作.Brackenbury 等人[17]提出了10 類常見的TAP 編程錯誤類型,作者發(fā)現(xiàn):錯誤的存在,使參與者更難正確預(yù)測規(guī)則的行為.Davidoff 等人[29]發(fā)現(xiàn),智能家居用戶的日常活動與編程任務(wù)并不匹配.論文描述了家庭想要的控制,并提出了有助于終端用戶編程系統(tǒng)實現(xiàn)這種控制的7 種設(shè)計原則.Brush 等人[20]認(rèn)為:為使智能家居得到更廣泛的使用,需要解決成本高昂、設(shè)備不靈活、客觀理性差和安全保障這4 個障礙.論文還為進(jìn)一步研究提供了幾個方向,包括消除變化結(jié)構(gòu)的需要、為用戶提供簡單的安全原語并支持家庭設(shè)備的組合.
因此,為減少終端用戶編程的錯誤,TAP平臺需要對用戶生成TAP規(guī)則進(jìn)行指導(dǎo),并實現(xiàn)模型的檢查,自動發(fā)現(xiàn)規(guī)則漏洞或沖突.Wang 等人[14]利用IFTTT 平臺,探討了在Triger-Action 平臺中可能存在的規(guī)則漏洞,并借助于自然語言處理的方法推斷Triger-Action 信息,實現(xiàn)了一個模型檢查系統(tǒng)iRuler,用于發(fā)現(xiàn)物聯(lián)網(wǎng)中的規(guī)則間漏洞.Celik 等人[19,30,31]認(rèn)為,物聯(lián)網(wǎng)中存在大量的設(shè)備交互.因此,不僅需要驗證單個設(shè)備,還需要對設(shè)備的聯(lián)合行為進(jìn)行檢查.Soteria[30]是一種靜態(tài)分析系統(tǒng),可從IoT 應(yīng)用程序的源代碼中提取狀態(tài)模型,并通過模型檢查來驗證IoT 應(yīng)用程序或IoT 環(huán)境是否符合已標(biāo)識的屬性.考慮到靜態(tài)分析在估計物聯(lián)網(wǎng)狀態(tài)轉(zhuǎn)換方面的局限性,Celik 等人[19]繼續(xù)開發(fā)了一個動態(tài)分析系統(tǒng)IoTGuard,可通過在運行時監(jiān)視設(shè)備執(zhí)行行為,來強制執(zhí)行已標(biāo)識的屬性,并可以通過阻止違反屬性的設(shè)備操作,或在運行時要求用戶批準(zhǔn)或拒絕違規(guī)操作來應(yīng)對屬性違規(guī).肖丁等人提出的基于知識圖譜的KGIID 算法[32]能夠檢測TAP 編程模型中沖突的動作(隱式?jīng)_突).孟巖等人提出的HODETECT 檢測工具[33]利用無線側(cè)信道技術(shù)從智能家居應(yīng)用中提取工作邏輯,并用有限狀態(tài)自動機建模,通過在應(yīng)用運行時監(jiān)聽無線加密流量的元數(shù)據(jù)來推測應(yīng)用的執(zhí)行狀態(tài),間接檢測惡意應(yīng)用.陳星等人[34]提出了智能家居情境感知服務(wù)的運行時建模與執(zhí)行方法,能夠降低開發(fā)者開發(fā)智能家居情境感知服務(wù)的難度和復(fù)雜度.
更進(jìn)一步地,TAP 服務(wù)提供平臺還需要對存在缺陷的規(guī)則進(jìn)行修復(fù).Nandi 等人[26]注意到,終端用戶在編寫規(guī)則時所犯的一個常見錯誤是觸發(fā)器數(shù)量不足.因此,作者開發(fā)了TrigGen,它可以根據(jù)規(guī)則中的操作自動生成一組必要和充分的觸發(fā)器,來幫助終端用戶正確地編寫規(guī)則.這種做法在一定程度上減少了意外行為和安全漏洞的發(fā)生率,但是其對于潛在沖突的檢測還有提升空間.為幫助非專業(yè)的物聯(lián)網(wǎng)用戶系統(tǒng)地實現(xiàn)高置信度的實時HA-IoT 系統(tǒng),Bu 等人[16]介紹了一種自動化端到端編程輔助框架MenShen,它能夠檢查自動化規(guī)則集是否違反規(guī)范,從而為用戶提供可能的解決方案.Zave 等人[24]建議在運行時通過優(yōu)先級來減少設(shè)備管理和交互的成本,并通過組合機制實現(xiàn)了目標(biāo).Zhang等人[15]將用戶需要表達(dá)的屬性轉(zhuǎn)換為線性時序邏輯(LTL),自動合成滿足屬性的TAP 規(guī)則,并修復(fù)現(xiàn)有的TAP 規(guī)則.
基于規(guī)則的智能家居系統(tǒng)是目前流行的一種智能家居系統(tǒng),而編寫瑣碎、修改困難、錯誤難以追蹤是以往用戶調(diào)查[15]所反映的問題.本文提出的SS 范式以及配套的SSRules 系統(tǒng)實現(xiàn)方式,使得用戶規(guī)則編寫和修改的復(fù)雜程度大為減低;同時,設(shè)計的SS 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯算法使得輸入的SS 規(guī)則能夠在現(xiàn)有的智能家居系統(tǒng)HA 規(guī)則引擎上運行,并且通過輔助的SSRules 運行時模塊,能夠提供規(guī)則執(zhí)行異常檢測的能力.
未來的工作重點在以下兩個方面:一方面,采用模型檢測技術(shù)實現(xiàn)對SS 范式無法避免的缺陷進(jìn)行檢測,并設(shè)計輔助用戶編寫SS 規(guī)則和避免缺陷的實時反饋算法;另一方面,對于SS 范式目前不能夠表達(dá)的需求,進(jìn)行用戶調(diào)查并尋找合適的多范式協(xié)同輸入對策.
猜你喜歡范式智能家居編程以寫促讀：構(gòu)建群文閱讀教學(xué)范式甘肅教育(2021年10期)2021-11-02范式空白：《莫失莫忘》的否定之維福建江夏學(xué)院學(xué)報(2021年6期)2021-08-10編程，是一種態(tài)度少先隊活動(2021年2期)2021-03-29元征X-431實測：奔馳發(fā)動機編程汽車維修與保養(yǎng)(2021年8期)2021-02-16編程小能手學(xué)生天地(2020年17期)2020-08-25孫惠芬鄉(xiāng)土寫作批評的六個范式大連民族大學(xué)學(xué)報(2020年2期)2020-06-16紡織機上誕生的編程數(shù)學(xué)大王·低年級(2020年3期)2020-03-12基于PLC的智能家居控制系統(tǒng)研究電子制作(2019年20期)2019-12-04管窺西方“詩辯”發(fā)展史的四次范式轉(zhuǎn)換英美文學(xué)研究論叢(2018年1期)2018-08-16基于Zigbee的無線通信技術(shù)在智能家居中的應(yīng)用電子制作(2018年1期)2018-04-04