SSRules:讓智能家居自動(dòng)化規(guī)則更易于編寫和檢查*

王 博,張 昱,耿佳寧,李向陽(yáng)

1(中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 下一代移動(dòng)計(jì)算與數(shù)據(jù)創(chuàng)新實(shí)驗(yàn)室,安徽 合肥 230027)

2(中國(guó)科學(xué)院 無(wú)線光電通信重點(diǎn)實(shí)驗(yàn)室,安徽 合肥 230027)

隨著物聯(lián)網(wǎng)、人工智能與5G 等創(chuàng)新技術(shù)驅(qū)動(dòng)的萬(wàn)物互聯(lián)時(shí)代的到來(lái),智能家居作為物聯(lián)網(wǎng)的重要應(yīng)用場(chǎng)景之一,正快速進(jìn)入千家萬(wàn)戶.智能家居令家庭中的各種設(shè)備互聯(lián)互通,使用戶實(shí)現(xiàn)設(shè)備的自動(dòng)控制、遠(yuǎn)程控制和可編程控制,甚至可以根據(jù)歷史經(jīng)驗(yàn)主動(dòng)進(jìn)行自動(dòng)化服務(wù).根據(jù)MarketWatch 發(fā)布的報(bào)告[1],2016 年,全球智能家居市值556.5 億美元,預(yù)計(jì)2025 年將達(dá)到1 742.4 億美元;同時(shí),中國(guó)的智能家居市場(chǎng)也在快速發(fā)展,據(jù)艾瑞咨詢發(fā)布的報(bào)告[2],2017 年,中國(guó)智能家居市場(chǎng)規(guī)模為3 254.7 億元,預(yù)計(jì)2020 年將達(dá)到5 819.3 億元.

為管理種類和規(guī)模不斷增加的智能設(shè)備,國(guó)內(nèi)外主要領(lǐng)導(dǎo)廠商紛紛推出智能家居平臺(tái),如三星的SmartThings、Amazon 的Alexa、Google 的Home、小米的米家、華為HiLink、云端規(guī)則定制平臺(tái)IFTTT(“IF This Then That”)[3]等,但它們幾乎不開(kāi)源并且僅支持相關(guān)品牌的設(shè)備,限制了用戶所能管控的設(shè)備類型及范圍;在開(kāi)源的智能家居平臺(tái)中,基于Python3 的HomeAssistant[4]相對(duì)成熟,支持多種操作系統(tǒng)/平臺(tái),集成了IFTTT、GoogleAssistant、MQTT 等產(chǎn)品/功能.這些智能家居平臺(tái)將要管控的設(shè)備抽象化,通過(guò)建立通信標(biāo)準(zhǔn)以及API互聯(lián)等方式連接設(shè)備和app,采用“觸發(fā)-動(dòng)作編程”(trigger-action programming,簡(jiǎn)稱TAP)[5]支持用戶定制規(guī)則以指定系統(tǒng)行為.但我們通過(guò)多次調(diào)研發(fā)現(xiàn):現(xiàn)有TAP 雖足以滿足終端用戶表達(dá)簡(jiǎn)單的自動(dòng)化任務(wù),但靈活性不足,難以支持更復(fù)雜的用例[5-8].

TAP 規(guī)則(如IFTTT)典型地將單個(gè)觸發(fā)器(trigger)與單個(gè)動(dòng)作(action)關(guān)聯(lián)起來(lái),例如“如果開(kāi)始下雨,則關(guān)窗”.然而,許多常見(jiàn)行為需要TAP 提供更強(qiáng)的表達(dá)能力,如對(duì)空調(diào)等復(fù)雜設(shè)備的設(shè)定、對(duì)門鎖窗戶等安全攸關(guān)設(shè)備的可靠設(shè)定、對(duì)夜燈/咖啡機(jī)等設(shè)備的工作持續(xù)時(shí)間設(shè)定等.為支持用戶的日常需求,不同的智能家居平臺(tái)提供不同的支持,例如引入and 連接多個(gè)觸發(fā)器[5]或者連接多個(gè)觸發(fā)器和多個(gè)動(dòng)作(如Stringify[9])、用更一般的and/or 組合多個(gè)觸發(fā)器或多個(gè)動(dòng)作(如HomeAssistant)、增加對(duì)觸發(fā)器的條件過(guò)濾(如Microsoft Flow[10],Zapier[11]和 HomeAssistant)、增加“狀態(tài)保持時(shí)長(zhǎng)”的表達(dá)能力(如 SmartRules[12])、支持自定義的事件/服務(wù)(如HomeAssistant).各種TAP 擴(kuò)展豐富了可定制性,但是也存在語(yǔ)義不清晰、編寫復(fù)雜等缺陷,不便于用戶使用.

隨著設(shè)備數(shù)量的增加,其交互也隨之增多,TAP 編程出錯(cuò)的可能性也會(huì)增加.針對(duì)這類問(wèn)題,一些研究如BuildingRules[13],IRuler[14]等提供對(duì)某些TAP 編程缺陷的檢測(cè);AutoTap[15]能由線性時(shí)序邏輯表達(dá)的設(shè)備性質(zhì)合成某些TAP 規(guī)則,從而避免用戶直接編寫TAP 規(guī)則;AutoTap 和Menshen[16]還提供有限的錯(cuò)誤修復(fù)功能.Brackenbury 等人[17]首次提出和規(guī)范可用于TAP 規(guī)則觸發(fā)器的3 種時(shí)序范式Event-Event,State-State 和Event- State,并總結(jié)了TAP 可能存在的10 種編程缺陷.

針對(duì)智能家居系統(tǒng)面臨的挑戰(zhàn),本文研究易寫易改、支持多觸發(fā)器-多動(dòng)作、支持狀態(tài)保持描述等能力的TAP 規(guī)則的表示,然后構(gòu)建支持這種規(guī)則表示的智能家居自動(dòng)化框架.在TAP 規(guī)則的表示方面,觸發(fā)器和動(dòng)作均可以分為(純)狀態(tài)型和事件型.本文首先系統(tǒng)分析和總結(jié)了各種TAP 編程范式以及它們引起的缺陷種類、原因和檢測(cè)/修復(fù)現(xiàn)狀,指出了改進(jìn)TAP 的可能渠道;然后,針對(duì)用戶不易分清事件和狀態(tài)、不易寫全規(guī)則所要考慮的情況組合以及“Event-trigger Event-action”(EE)風(fēng)格的規(guī)則冗長(zhǎng)、更改瑣碎等特征,本文提出以“State-trigger State-action”(SS)為基礎(chǔ)構(gòu)建面向終端用戶易寫易改的、具有豐富表達(dá)能力的具體SS 規(guī)則范式.在自動(dòng)化框架構(gòu)建方面,鑒于HomeAssistant(簡(jiǎn)稱HA)相對(duì)成熟和開(kāi)源,支持多種平臺(tái)和多種設(shè)備及服務(wù)集成方式,提供以Event 為核心的寬泛TAP 配置,本文以它為基礎(chǔ)構(gòu)建支持SS 規(guī)則范式的智能家居自動(dòng)化框架SSRules.針對(duì)Brackenbury 等人[17]指出的10 種TAP 缺陷,采用SS 規(guī)則范式能天然排除時(shí)間窗錯(cuò)誤和翻轉(zhuǎn)觸發(fā)器這2 種缺陷,完全避免優(yōu)先級(jí)沖突;結(jié)合SSRules 的實(shí)現(xiàn)策略,能部分解決或消除安全默認(rèn)偏差、非瞬時(shí)動(dòng)作、重復(fù)觸發(fā)這3種缺陷,并附帶改善缺少反向動(dòng)作的缺陷;對(duì)于無(wú)限循環(huán)和不確定時(shí)序這兩種缺陷,可以通過(guò)模型檢查等方法在規(guī)則轉(zhuǎn)譯成HA 之前避免;SSRules 尚不能解決矛盾的動(dòng)作這種缺陷.本文的主要貢獻(xiàn)如下:

(1) 系統(tǒng)分析和總結(jié)了TAP 編程范式及其編程缺陷,指出了改進(jìn)TAP 的幾種可能渠道,為我國(guó)智能家居領(lǐng)域從業(yè)者和軟件研發(fā)人員全面了解TAP 編程、缺陷及改進(jìn)提供了參考資料;

(2) 提出以“State-trigger State-action”為基礎(chǔ)構(gòu)建易寫易改、有豐富表達(dá)力的TAP 編程范式.SS 規(guī)則范式以實(shí)體-能力抽象為基礎(chǔ),按動(dòng)作實(shí)體將規(guī)則分組、組內(nèi)按序優(yōu)先,有效避免了優(yōu)先級(jí)沖突;它區(qū)分只讀和可控能力,提供4 種表示歷史狀態(tài)的算符,并方便表達(dá)在指定狀態(tài)/狀態(tài)保持下對(duì)多種能力的期望;

(3) 引入能表達(dá)事件型智能家居執(zhí)行引擎的獨(dú)立“Event-trigger Event-action”(EE)中間表示,基于HA 構(gòu)建智能家居自動(dòng)化框架SSRules,它能將SS 規(guī)則集合經(jīng)EE 規(guī)則表示轉(zhuǎn)譯成HA 規(guī)則,利用Z3 定理證明器[18]進(jìn)行觸發(fā)事件的篩選和規(guī)則化簡(jiǎn),并提供運(yùn)行時(shí)子系統(tǒng)動(dòng)態(tài)感知設(shè)備變化和檢查規(guī)則執(zhí)行的有效性;

(4) 實(shí)現(xiàn)了智能家居模擬器和SSRules 原型系統(tǒng).對(duì)10 組測(cè)試場(chǎng)景,用SS 范式編寫所需的規(guī)則條數(shù)比轉(zhuǎn)譯和合并后得到的EE 范式規(guī)則數(shù)平均減少了60%左右;在模擬實(shí)驗(yàn)環(huán)境下,最終生成的HA 規(guī)則的運(yùn)行時(shí)檢查都未發(fā)現(xiàn)連續(xù)異常,并且所記錄到的瞬時(shí)異常(小于總檢查次數(shù)的0.3%)經(jīng)查閱日志均為網(wǎng)絡(luò)延遲引起.

本文第1 節(jié)對(duì)現(xiàn)有TAP 編程范式及其引起的缺陷、易用性以及缺陷檢查和修復(fù)現(xiàn)狀進(jìn)行總結(jié).第2 節(jié)提出智能家居自動(dòng)化框架的設(shè)計(jì)目標(biāo),對(duì)以HA 為底層基礎(chǔ)、以SS 規(guī)則范式為用戶輸入的智能家居自動(dòng)化框架SSRules 的總體設(shè)計(jì)進(jìn)行總結(jié).第3 節(jié)詳細(xì)討論SS 規(guī)則范式的定義及其到HA 規(guī)則的轉(zhuǎn)譯方法.第4 節(jié)介紹基于HA 構(gòu)建的智能家居模擬環(huán)境,并在該模擬環(huán)境上評(píng)估了SSRules 的有效性.第5 節(jié)和第6 節(jié)分別對(duì)相關(guān)工作和本文的工作進(jìn)行總結(jié).

1 TAP 編程范式及缺陷分析

為了滿足終端用戶靈活多樣的需求,大多數(shù)智能家居平臺(tái)都提供特定的TAP 編程接口用于對(duì)智能設(shè)備和/或服務(wù)進(jìn)行編程,以定制智能家居系統(tǒng)的行為.本節(jié)首先對(duì)TAP 編程范式進(jìn)行了詳細(xì)分析,然后系統(tǒng)總結(jié)分析了可能導(dǎo)致TAP 缺陷的原因,最后簡(jiǎn)要總結(jié)改進(jìn)TAP 的可能渠道.

1.1 TAP編程范式概述

TAP 的表達(dá)能力及易寫易改性,對(duì)智能家居的推廣和普及至關(guān)重要.目前最流行的TAP 接口是IFTTT 在線服務(wù)[3],它允許用戶創(chuàng)建程序、自動(dòng)執(zhí)行由單個(gè)事件觸發(fā)的動(dòng)作,盡管IFTTT 應(yīng)用廣泛,但其表達(dá)能力非常受限.

? 多觸發(fā)器、多動(dòng)作

根據(jù)Ur 等人的用戶調(diào)查[5],22%的編程行為需要不止一個(gè)觸發(fā)器或動(dòng)作,并且觸發(fā)器和動(dòng)作在用戶期望的行為中的組合也更為多樣化.因此,Ur 等人引入“and”連接觸發(fā)同一動(dòng)作的多個(gè)事件,例如“IF 窗戶是開(kāi)的and 在下雨”就觸發(fā)“關(guān)窗”.Zapier[11]允許將多個(gè)動(dòng)作綁定到一個(gè)觸發(fā)器;Stringify[9]支持形如“If This and This,Then That and That”的規(guī)則.HA[4]還允許定制只要多個(gè)觸發(fā)器中任意一個(gè)被觸發(fā)就執(zhí)行的規(guī)則.

? 條件過(guò)濾與工作流控制

Zapier 和HA 提供過(guò)濾器,支持對(duì)觸發(fā)器的進(jìn)一步(and/or)條件過(guò)濾.例如:可以在觸發(fā)器“接收郵件”后追加過(guò)濾器“主題包含X and 來(lái)自Y”;MicrosoftFlow[10]不僅提供多步驟的工作流,還提供If-then-else 條件過(guò)濾、For-Each 和Do-While 循環(huán)等;HA 允許定制包含“call service”動(dòng)作、自定義事件和自定義觸發(fā)器的規(guī)則,允許開(kāi)發(fā)者編程實(shí)現(xiàn)各種服務(wù).Flow 和HA 提供的這些功能非常強(qiáng)大,但是對(duì)終端用戶編程的能力要求高,且缺少對(duì)用戶配置的有效性檢查.

? 區(qū)分事件(event)與狀態(tài)(state)

IFTTT 的“if this then that”易被理解為通用編程中的if-then 語(yǔ)句,而其實(shí)際語(yǔ)義卻等價(jià)于事件驅(qū)動(dòng)編程.Huang 等人[6]認(rèn)為:把IFTTT 隱喻成if-then 會(huì)有歧義,這種歧義會(huì)給用戶帶來(lái)困難.由此提出用事件和狀態(tài)區(qū)分觸發(fā)器:事件是瞬時(shí)信號(hào)(如“溫度降到10°C 以下”),而狀態(tài)是可隨時(shí)評(píng)價(jià)的布爾條件(如“在下雨”).Brackenbury等人[17]進(jìn)一步將動(dòng)作分成事件(在特定時(shí)刻發(fā)生,如“關(guān)燈”)和狀態(tài)(一段時(shí)間內(nèi)設(shè)備的期望狀態(tài),如“燈應(yīng)亮著”)兩類.這種區(qū)分事件和狀態(tài)的TAP 看似消除了一些歧義,潛在簡(jiǎn)化了系統(tǒng)實(shí)現(xiàn)中對(duì)TAP 規(guī)則的理解,但是研究表明:終端用戶往往很難清晰區(qū)分事件和狀態(tài)[6],且它們的組合又引出新問(wèn)題.

? 事件和狀態(tài)的組合

事件和狀態(tài)在組合時(shí)有以下語(yǔ)義:多個(gè)狀態(tài)si的合取是另一個(gè)狀態(tài)s,僅當(dāng)每個(gè)si為真時(shí)s 為真;狀態(tài)s 與事件e 的合取是在s為真時(shí)e 同時(shí)發(fā)生的另一個(gè)事件e′;兩個(gè)事件e1和e2的合取是與e1和e2同時(shí)發(fā)生的另一個(gè)事件.然而在智能家居系統(tǒng)中,“事件同時(shí)發(fā)生”無(wú)論是理論還是實(shí)際都不太可能發(fā)生.Brackenbury 等人[17]提出了3 種多觸發(fā)器組合的時(shí)序范式:Event-Event,Event-State 和State-State,并將它們與動(dòng)作組合成表1 所示的4 類TAP 規(guī)則.其中:Event-Event 時(shí)序范式引入 WITHIN 時(shí)間窗口子句來(lái)描述不能同時(shí)發(fā)生的事件,并提供AFTERWARDS 指定事件次序;Event-State 時(shí)序范式將觸發(fā)器限制為一個(gè)帶若干狀態(tài)的事件.這兩類觸發(fā)器均觸發(fā)事件型動(dòng)作,也是真實(shí)智能家居系統(tǒng)主要采取的方式.State-State 觸發(fā)器范式組合多個(gè)狀態(tài)并且狀態(tài)會(huì)在一段時(shí)間內(nèi)滿足,故自然地觸發(fā)狀態(tài)動(dòng)作;考慮到影響同一設(shè)備的多條規(guī)則的多個(gè)狀態(tài)可能同時(shí)為真(如控制空調(diào)的模式),故State-State→State 范式需要包含優(yōu)先級(jí)來(lái)解決沖突.此外,對(duì)于少數(shù)不能直接表示為狀態(tài)型的離散事件動(dòng)作(如“記錄日志”),State-State 時(shí)序范式會(huì)觸發(fā)事件動(dòng)作.

? 狀態(tài)保持性描述

Huang 等人[6]將動(dòng)作分成瞬時(shí)動(dòng)作(如“發(fā)郵件”)、在固定時(shí)間完成的動(dòng)作(如“沖泡咖啡”)、包含改變狀態(tài)的持續(xù)性動(dòng)作(如“開(kāi)燈”),這給智能家居系統(tǒng)提出了描述和實(shí)現(xiàn)狀態(tài)保持特性的需求.SmartRules 提供“狀態(tài)保持”的表達(dá),可以創(chuàng)建“如果門開(kāi)著有5 分鐘就通知”之類的動(dòng)作.HA 提供的trigger 可以定時(shí),雖然其action 沒(méi)有直接提供保持時(shí)長(zhǎng)的表示方法,但是它提供的callservice 動(dòng)作潛在允許開(kāi)發(fā)者編寫處理狀態(tài)保持時(shí)長(zhǎng)等服務(wù)的能力,因此也可以實(shí)現(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í)很容易出錯(cuò),原因在于智能家居設(shè)備眾多、用戶期望的行為復(fù)雜多樣、智能家居設(shè)備之間存在大量的交互[19],單個(gè)設(shè)備會(huì)直接或間接影響到其他設(shè)備.人的行為也會(huì)影響設(shè)備狀態(tài),而人的即使看似簡(jiǎn)單的行為也可能會(huì)引起背后復(fù)雜的設(shè)備行為;且人的行為與需求并非一成不變,在不同的場(chǎng)景需求下,很可能會(huì)造成對(duì)已有規(guī)則的破壞[20].由于智能家居的用戶通常缺乏編程相關(guān)的訓(xùn)練,為降低編程門檻,TAP 過(guò)分簡(jiǎn)化了操作界面[6],從而使程序的表達(dá)能力變差,這進(jìn)一步惡化了TAP 對(duì)復(fù)雜行為的可解釋性.

Brackenbury 等人[17]通過(guò)用戶調(diào)查,總結(jié)出可能出現(xiàn)在TAP 的10 種缺陷,包括:

(1) 4 種缺陷已被發(fā)現(xiàn)且詳細(xì)討論

① 優(yōu)先級(jí)沖突(priority conflict),僅在采用State-State→State 時(shí)需要對(duì)作用于同一設(shè)備的多條規(guī)則進(jìn)行優(yōu) 先級(jí)排序,而用戶往往難以按自己的意圖正確設(shè)置規(guī)則優(yōu)先級(jí)[21].這種缺陷已被TAP 文獻(xiàn)廣泛討 論[7,13,22-24],可以通過(guò)靜態(tài)分析來(lái)檢測(cè);

② 安全默認(rèn)偏差(secure-default bias)發(fā)生在用戶默認(rèn)系統(tǒng)處在安全狀態(tài)[21](例如夜間鎖住窗口),但廣泛部 署的Event–State 設(shè)備沒(méi)有默認(rèn)狀態(tài),Yarosh 等人詳細(xì)討論了門鎖的這種缺陷[21];

③ 非瞬時(shí)動(dòng)作(extended action)源于動(dòng)作發(fā)生在一段時(shí)間而不是瞬時(shí)的(如沖泡咖啡);

④ 缺少反向動(dòng)作(missing reversal)發(fā)生在用戶創(chuàng)建了一條執(zhí)行某動(dòng)作的規(guī)則而沒(méi)有寫撤銷該動(dòng)作的規(guī)則 時(shí),例如寫了“IF 進(jìn)客廳 THEN 開(kāi)燈”但忘寫離開(kāi)關(guān)燈的規(guī)則,但用戶可能認(rèn)為系統(tǒng)會(huì)自動(dòng)關(guān)燈[6,21].

Huang 等人[6]詳細(xì)討論了缺陷③和缺陷④,并對(duì)系統(tǒng)接口提出改進(jìn)建議.缺陷④可以通過(guò)靜態(tài)分析檢測(cè),但不總能被修復(fù).

(2) 3 種缺陷被提及

⑤ 無(wú)限循環(huán)(infinite loop)的原因是規(guī)則相互觸發(fā),這種缺陷在機(jī)器人終端用戶編程中常被遇到[6];

⑥ 重復(fù)觸發(fā)(repeated triggering)指用戶希望規(guī)則僅觸發(fā)一次,但卻觸發(fā)多次.這種缺陷主要出現(xiàn)在State- State 范式下因狀態(tài)觸發(fā)器持續(xù)為真導(dǎo)致規(guī)則觸發(fā)多次.Cao 等人[25]在mashup 編程工作中提及了這種 缺陷;

⑦ 不確定的時(shí)序(nondeterministic timing)是由于系統(tǒng)處理同時(shí)發(fā)生的觸發(fā)器的順序不確定而導(dǎo)致.Huang 等人[6]簡(jiǎn)要討論了TAP 中存在的這種缺陷.

這3 種缺陷均可以通過(guò)靜態(tài)分析來(lái)檢測(cè),但是實(shí)際系統(tǒng)無(wú)法鑒別重復(fù)觸發(fā)是否是用戶的有意行為.缺陷⑤和缺陷⑦還可以通過(guò)動(dòng)態(tài)分析檢測(cè).

(3) TAP 新增缺陷

⑧ 矛盾的動(dòng)作(contradictory action)指的是長(zhǎng)周期內(nèi)在矛盾的動(dòng)作間無(wú)限循環(huán)(例如加熱和冷卻之間不斷 交替);

⑨ 時(shí)間窗錯(cuò)誤(time-window fallacy)是當(dāng)用戶在編寫Event-Event 范式的規(guī)則時(shí)忘指定時(shí)間窗時(shí)導(dǎo)致;

⑩ 翻轉(zhuǎn)觸發(fā)器(flipped triggers)是因用戶難以指定觸發(fā)器中哪部分是事件哪部分是狀態(tài)而導(dǎo)致的.這種缺 陷在靜態(tài)或動(dòng)態(tài)分析中都很難檢測(cè)到.

表2 總結(jié)了上述10 種缺陷的原因、引起缺陷的TAP 編程范式、缺陷檢查或修復(fù)方法.

Table 2 Causes and detection of various bugs in TAP rules表2 各種TAP 缺陷的起因與可檢測(cè)性

10 種缺陷中,第①種、第②種、第④種、第⑨種、第⑩種歸結(jié)為與用戶預(yù)期不一樣,第③種、第⑦種為時(shí)序缺陷,剩余3 種為控制流缺陷.表中第3 列的“All”表示表1 中的4 類TAP 規(guī)則都可能引起這種缺陷.從中可見(jiàn):第①種和第③種這兩種缺陷僅存在于純狀態(tài)觸發(fā)器的TAP 編程中,而第⑨種、第⑩種僅存在于含事件的觸發(fā)器的TAP 編程中.Brackenbury 等人[17]對(duì)這10 種缺陷的進(jìn)一步用戶調(diào)查表明:相比Event-State,問(wèn)卷參與者使用State-State 能寫得更正確,而使用Event-Event 則正確性要差些.

1.3 改進(jìn)TAP的可能渠道

現(xiàn)有的TAP 平臺(tái)尚未能充分滿足用戶需求,在實(shí)際運(yùn)行中容易出現(xiàn)缺陷導(dǎo)致系統(tǒng)出錯(cuò).綜合分析現(xiàn)有智能家居系統(tǒng)及學(xué)術(shù)研究成果,以下給出了幾種改進(jìn)TAP、減少編程缺陷的渠道.

(1) TAP 編程范式

實(shí)際智能家居系統(tǒng)大都基于Event-State→Event 規(guī)則范式來(lái)實(shí)現(xiàn).相比于使用事件型觸發(fā)器進(jìn)行TAP 編程,使用純狀態(tài)觸發(fā)器更容易讓終端用戶正確表達(dá)意圖.即使使用相同的觸發(fā)器范型和動(dòng)作范型,不同的TAP 規(guī)則結(jié)構(gòu)仍會(huì)影響TAP 編程的表達(dá)能力、易用性和編程缺陷.現(xiàn)有解決方案中,除了直接讓終端用戶寫TAP 規(guī)則,研究人員還提出了不同的實(shí)現(xiàn)方案,如:

? AutoTap[15]允許用戶輸入設(shè)備的安全性質(zhì)(可轉(zhuǎn)化為線性時(shí)序邏輯公式)而由系統(tǒng)合成Event-State→ Event 規(guī)則,從而減少最終規(guī)則的缺陷,但是存在合成效率較低、難以適用較多設(shè)備、安全性質(zhì)不適合表達(dá)需求細(xì)節(jié)等不足;

? Zave 等人[24]提出讓用戶對(duì)設(shè)備按不同目的(如安全性、節(jié)能等)分別描述需求特征,然后手工為特征建立狀態(tài)機(jī),并根據(jù)它設(shè)計(jì)運(yùn)行時(shí)的特征組合機(jī)制來(lái)實(shí)時(shí)控制執(zhí)行器.如何由非形式的特征描述建立FSM 以及解決特征沖突(或稱特征交互)是其中的難點(diǎn),該方法目前只支持對(duì)幾種設(shè)備的人工建模且僅支持“值設(shè)置”動(dòng)作.

(2) TAP 規(guī)則的檢查與修復(fù)

改進(jìn)TAP 編程范式不可能完全消除編程缺陷,TAP 平臺(tái)仍需要一些額外的工具或方法來(lái)檢查TAP 規(guī)則的有效性,并嘗試修復(fù)規(guī)則.現(xiàn)有的方法大都針對(duì)Event-State→Event 規(guī)則進(jìn)行靜態(tài)檢查(如IRuler[14],AutoTap[15],MenShen[16,22])、動(dòng)態(tài)檢查(IoTGuard[19])或規(guī)則修復(fù)(AutoTap,MenShen,TrigGen[26]),僅有極個(gè)別方案是基于狀態(tài)觸發(fā)的[21,24],這很大程度上是因?yàn)閷?shí)際的智能家居系統(tǒng)是按事件驅(qū)動(dòng)方式來(lái)運(yùn)行的.表3 從多種維度比較了已有方法,可以看出,Event-State→Event 規(guī)則的修復(fù)存在搜索修復(fù)策略低效以及在不清楚用戶意圖的情況下仍需用戶決策等局限性.而隨著設(shè)備數(shù)增多,這類規(guī)則及修復(fù)邏輯的可讀/可理解性也在下降.此外,由于網(wǎng)絡(luò)延遲/重放攻擊等,也會(huì)使基于EE 的智能家居系統(tǒng)執(zhí)行不期望的動(dòng)作.Wang 等人[27]提出,通過(guò)分析日志中事件間的依賴來(lái)事后追因.

Table 3 Existing work towards bugsin smart home rules表3 關(guān)于智能家居用戶規(guī)則缺陷的相關(guān)工作

(3) 智能家居系統(tǒng)的實(shí)現(xiàn)

對(duì)TAP 規(guī)則的靜態(tài)檢測(cè)和修復(fù)可以在規(guī)則實(shí)際運(yùn)行前識(shí)別出部分規(guī)則缺陷,并嘗試手工/自動(dòng)修復(fù).但是如表2 第4 列所說(shuō),還有許多缺陷是靜態(tài)無(wú)法檢測(cè),或是由于難以判斷用戶意圖從而無(wú)法確定缺陷是否存在.因此,智能家居系統(tǒng)在實(shí)現(xiàn)時(shí)需要提供:

1) 給用戶更多的提示和警告:針對(duì)那些潛在有歧義、有沖突或已做動(dòng)作不會(huì)被自動(dòng)撤銷等情況,系統(tǒng)要給出用戶易于理解的提示或警告;

2) 提供不易讓用戶混淆的選項(xiàng)供用戶選擇;

3) 提供運(yùn)行時(shí)日志的記錄,需要權(quán)衡日志的存儲(chǔ)量與事后推理的便利性;

4) 支持和提供含義更明確的頂層trigger-action 結(jié)構(gòu),等等.

2 SSRules 智能家居系統(tǒng)總體設(shè)計(jì)

為使終端用戶易于編程,本文重點(diǎn)探索狀態(tài)觸發(fā)器-狀態(tài)動(dòng)作的TAP 編程范式(簡(jiǎn)稱SS 規(guī)則范式),并基于HA 構(gòu)建了支持SS 規(guī)則范式輸入的SSRules 系統(tǒng).SSRules 在不改變HA 規(guī)則執(zhí)行引擎的基礎(chǔ)上,擴(kuò)展提供更易被用戶理解和掌握的規(guī)則表達(dá)方式以及對(duì)應(yīng)的規(guī)則轉(zhuǎn)譯器.雖然SS 規(guī)則范式尚不支持表達(dá)無(wú)狀態(tài)或難以抽象出狀態(tài)的事件動(dòng)作,但由于這類動(dòng)作所占比重小、用戶需求低,因此,SSRules 可以支持用戶的絕大多數(shù)需求.未來(lái)可以設(shè)計(jì)專門的機(jī)制,將這些無(wú)狀態(tài)的事件動(dòng)作加入到SSRules 系統(tǒng)中.本節(jié)首先簡(jiǎn)要介紹SSRules 的設(shè)計(jì)目標(biāo),然后分析HA 的關(guān)鍵特征,最后給出SSRules 總體架構(gòu)以及所引入的Entity-Capability 抽象.

2.1 設(shè)計(jì)目標(biāo)

智能家居正進(jìn)入尋常百姓家,為了讓SSRules 滿足用戶的不同需求,現(xiàn)階段至少應(yīng)圍繞如下目標(biāo)設(shè)計(jì).

G1.易寫易改.針對(duì)用戶調(diào)查[5,6,15,17]反映的TAP 規(guī)則編寫和修改的問(wèn)題,SSRules 應(yīng)提供讓無(wú)編程經(jīng)驗(yàn)的終端用戶快速學(xué)習(xí)并正確使用的編程范式,方便表達(dá)所期望的智能家居系統(tǒng)性質(zhì),且在需求變化時(shí)容易修改;

G2.可管可控.SSRules 系統(tǒng)應(yīng)能提供按終端用戶的有效需求對(duì)來(lái)自不同廠商的設(shè)備實(shí)時(shí)監(jiān)測(cè)與控制,感知系統(tǒng)中動(dòng)態(tài)加入和退出的管控對(duì)象,而不能只支持特定廠商的設(shè)備和僅提供極其有限的監(jiān)測(cè)能力;

G3.異常檢測(cè).智能家居系統(tǒng)的可靠性受限于網(wǎng)絡(luò)、設(shè)備故障等不定因素,而用戶希望系統(tǒng)提供實(shí)時(shí)反饋以及對(duì)系統(tǒng)更多的控制感.因此,系統(tǒng)需要能夠幫助用戶監(jiān)視運(yùn)行狀況,并將異常信息反饋給用戶;

G4.協(xié)調(diào)需求.作用于同一設(shè)備的多種需求存在沖突,是智能家居中的常見(jiàn)現(xiàn)象.系統(tǒng)要提供簡(jiǎn)單的處理方式,便于用戶協(xié)調(diào)好同一設(shè)備存在沖突的多種需求.例如希望燈在夜間關(guān)閉,但是有人經(jīng)過(guò)則應(yīng)以較低亮度打開(kāi)一段時(shí)間,如果遇到緊急情況(如廚房著火)則應(yīng)當(dāng)完全打開(kāi);

G5.多方信息.智能家居系統(tǒng)的功能邊界應(yīng)當(dāng)不限于家庭的物理空間.系統(tǒng)不僅要能夠處理家庭中存在的物理設(shè)備,也要能處理虛擬傳感器和虛擬的設(shè)備,如情景模式、天氣、時(shí)鐘等.

2.2 HomeAssistant(HA)

本文的研究重點(diǎn)為探索TAP 編程的表示及其在現(xiàn)有執(zhí)行引擎的實(shí)現(xiàn),同時(shí)提供一定的規(guī)則有效性檢查功能.因此,為更有效地實(shí)現(xiàn)G2 和G5 涉及的目標(biāo),SSRules 需要選擇成熟開(kāi)源的智能家居執(zhí)行引擎來(lái)實(shí)現(xiàn)與各種(虛擬)設(shè)備的連接、實(shí)時(shí)監(jiān)控、動(dòng)態(tài)感知以及自動(dòng)化管理等.

在開(kāi)源智能家居系統(tǒng)中,HA 是基于Python 的成熟智能家居開(kāi)源系統(tǒng),能部署在任何能運(yùn)行Python 3 的機(jī)器上,從樹(shù)莓派到網(wǎng)絡(luò)存儲(chǔ),還可以使用Docker 部署到其他系統(tǒng)上.它主要根據(jù)automations.yaml 等配置文件實(shí)現(xiàn)集中化的智能家居設(shè)備管理,設(shè)備支持度高,具有自動(dòng)化、群組化、UI 客制化等高度定制化設(shè)置;同時(shí),其開(kāi)發(fā)者數(shù)量、版本更新速度在所有開(kāi)源項(xiàng)目中也都屬于佼佼者.因此,我們最終選取HA 作為SSRules 的執(zhí)行引擎.

? 靈活的集成方式

在HA 中,物理設(shè)備和虛擬設(shè)備均被抽象為實(shí)體,帶有狀態(tài)的實(shí)體可以與狀態(tài)對(duì)象關(guān)聯(lián).天氣、太陽(yáng)角度等均為HA 預(yù)置的虛擬實(shí)體;通過(guò)用戶自定義或第三方集成,還可以實(shí)現(xiàn)如模式開(kāi)關(guān)、空氣質(zhì)量、用戶位置等虛擬傳感器和動(dòng)作器.實(shí)體上可以執(zhí)行的動(dòng)作被抽象為服務(wù)調(diào)用,除了HA 自帶的值變化事件、服務(wù)調(diào)用事件等事件類型,第三方集成也能夠發(fā)布其他自定義的事件.采用HA 可以自然地支持目標(biāo)G5.

? 設(shè)備的動(dòng)態(tài)管理

HA 接入設(shè)備的方式之一是MQTT Discovery,它提供對(duì)基于MQTT(message queuing telemetry transport)協(xié)議通信的設(shè)備的自動(dòng)發(fā)現(xiàn)、配置和移除.MQTT 協(xié)議是一種基于TCP 的發(fā)布訂閱協(xié)議,在物聯(lián)網(wǎng)通信中使用較多.設(shè)備接入HA 時(shí),每個(gè)設(shè)備只需按照HA 指定的格式配置其MQTT 通信模塊,HA 即可間接從MQTT 代理獲得配置信息并完成配置流程.若設(shè)備需要移除,則它可以更新?tīng)顟B(tài)信息將自己移除,也可以由HA 根據(jù)超時(shí)設(shè)置自動(dòng)移除.因此,HA 提供實(shí)現(xiàn)G2 的基礎(chǔ),SSRules 需要主動(dòng)與HA 交互真正達(dá)到G2.

? 高自由度的輸入

HA 的規(guī)則輸入語(yǔ)言為Trigger-Condition-Action(即Event-State→Event)范式,單規(guī)則中可以含有多觸發(fā)器、多動(dòng)作.動(dòng)作不僅可以是與設(shè)備相關(guān)的服務(wù)調(diào)用,也可以是自定義的事件觸發(fā)和狀態(tài)值寫入、HTTP 接口調(diào)用等,自由度很高.但是HA 的自動(dòng)化規(guī)則的編寫非常繁瑣,用戶難以使用其描述有優(yōu)先級(jí)的功能需求,并且用戶自行推理編寫極易遺漏或?qū)戝e(cuò).此外,由于HA 的實(shí)體狀態(tài)和服務(wù)調(diào)用之間的松耦合,HA 提供運(yùn)行時(shí)異常檢查極其有限.HA 在G1,G3 和G4 方面較弱,因此,這也是SSRules 要重點(diǎn)解決的問(wèn)題.

2.3 SSRules系統(tǒng)總體架構(gòu)

SSRules 系統(tǒng)總體架構(gòu)如圖1 所示.整個(gè)系統(tǒng)通過(guò)HA 提供的接口與智能家居設(shè)備連接,包括通過(guò)MQTT 代理連接智能家居真實(shí)設(shè)備或模擬器.系統(tǒng)由離線的轉(zhuǎn)譯器子系統(tǒng)和在線的SSRules 運(yùn)行時(shí)子系統(tǒng)組成:前者提供終端用戶輸入的SS 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯,后者提供HA 抽象信息的獲取和規(guī)則執(zhí)行的有效性檢查.SSRules引入Entity-Capability 抽象(見(jiàn)第2.4 節(jié))來(lái)描述智能家居系統(tǒng)所能管控的設(shè)備(實(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 中的實(shí)體、狀態(tài)、服務(wù)的抽象信息用于SS 規(guī)則的轉(zhuǎn)譯和異常檢測(cè),這些信息由SSRules運(yùn)行時(shí)子系統(tǒng)的抽象信息獲取模塊來(lái)提取和更新.該模塊定期從HA 更新實(shí)體信息并檢測(cè)變化情況,獲取設(shè)備的動(dòng)態(tài)信息(加入或離開(kāi)),生成SSRules 所需的最新實(shí)體-能力抽象信息和動(dòng)作翻譯信息.

? 規(guī)則轉(zhuǎn)換流程

SSRules 的用戶交互模塊根據(jù)實(shí)體-能力抽象信息將用戶輸入規(guī)則所需的信息以用戶友好的方式呈現(xiàn)在前端界面中.用戶完成編輯后,用戶交互模塊根據(jù)用戶的輸入生成SS 規(guī)則文件.接著,SSRules 運(yùn)行時(shí)系統(tǒng)會(huì)調(diào)用可離線運(yùn)行的轉(zhuǎn)譯器將SS 規(guī)則轉(zhuǎn)譯成HA 規(guī)則,再將其更新到HA 的automations.yml 中.

? 異常檢測(cè)設(shè)計(jì)

當(dāng)由SS 規(guī)則翻譯得到HA 規(guī)則并開(kāi)始執(zhí)行之后,規(guī)則執(zhí)行有效性檢查模塊會(huì)從HA 獲取所關(guān)心的狀態(tài)變化事件,定期獲取全部實(shí)體的狀態(tài),檢查實(shí)體狀態(tài)及其狀態(tài)變化是否符合SS 規(guī)則的描述,并將因網(wǎng)絡(luò)/設(shè)備故障等問(wèn)題導(dǎo)致的設(shè)備狀態(tài)與SS 規(guī)則描述不相符等情況進(jìn)行告警以及寫入日志.

2.4 Entity-Capability抽象

一個(gè)智能家居系統(tǒng)所管理的設(shè)備可以包括真實(shí)物理設(shè)備(如空調(diào))、虛擬設(shè)備(如天氣、時(shí)鐘等),還可以是人.SSRules 系統(tǒng)使用實(shí)體-能力抽象(entity-capability abstraction)來(lái)描述智能家居系統(tǒng)中各種設(shè)備的可感知和/ 或可控制的能力,記為,ND為實(shí)體總數(shù).每個(gè)設(shè)備抽象為一個(gè)實(shí)體E(entity),每個(gè)實(shí)體由其ID e、一組能力C(capability)以及描述各能力狀態(tài)之間轉(zhuǎn)移關(guān)系的狀態(tài)機(jī)M組成,即E=(e,C,M).

? 能力

每種能力表示單個(gè)可變化的只讀或者可控屬性.表4 列出了幾種常見(jiàn)智能家居設(shè)備及其能力.每種能力可 表示為一個(gè)四元組(c,k,ro,J),其中:c是該能力在實(shí)體內(nèi)的唯一標(biāo)識(shí);k表示該能力的狀態(tài)值類型,可以是二值 (binary)/多值(set)/實(shí)數(shù)(numeric)等類型之一(實(shí)數(shù)可以細(xì)分成子界類型或?qū)崝?shù)區(qū)間等,本文為簡(jiǎn)便起見(jiàn)不作區(qū) 分);布爾量ro為真表示能力是只讀的、為假表示是可控的;J表示一組關(guān)聯(lián)的命令序列,其中每個(gè)元素是要執(zhí)行 的命令代號(hào).

? 狀態(tài)機(jī)

每個(gè)實(shí)體的狀態(tài)機(jī)由該實(shí)體每種能力c 的狀態(tài)機(jī)組成:Mc=(Vc,Tc),其中,Vc是能力c 的狀態(tài)值集合,Tc是狀 態(tài)值之間的轉(zhuǎn)移函數(shù).

Table 4 Examples of entities and their capabilities表4 實(shí)體及能力舉例

在缺省的Mc中,任意兩個(gè)狀態(tài)值之間存在條件為True 的轉(zhuǎn)移(即無(wú)條件狀態(tài)轉(zhuǎn)移);若c 可控,則存在無(wú)條件 動(dòng)作,它可觸發(fā)任意兩個(gè)狀態(tài)值之間的狀態(tài)轉(zhuǎn)移.SSRules 系統(tǒng)會(huì)提供初始的Mc配置文件,其中提供部分常用 設(shè)備能力及其狀態(tài)轉(zhuǎn)移描述,用戶也可以根據(jù)需要添加某個(gè)設(shè)備或者某一類設(shè)備的Mc補(bǔ)充信息.

根據(jù)c 的Mc抽象,可以進(jìn)一步檢測(cè)動(dòng)作的執(zhí)行前提,或者判斷事件的可能性.例如,假設(shè)電扇和咖啡機(jī)的能力狀態(tài)機(jī)如圖2 所示:① 電扇的c2(風(fēng)速)只有在其c1(開(kāi)關(guān))的取值為開(kāi)時(shí)才可以接受改變風(fēng)速的動(dòng)作;② 咖啡機(jī)的咖啡狀態(tài)僅在咖啡機(jī)的c1(開(kāi)關(guān))取值為開(kāi)時(shí)才能從未準(zhǔn)備好進(jìn)入準(zhǔn)備好狀態(tài).

Fig.2 The state machines for each capability of the fan and coffee machine圖2 電扇和咖啡機(jī)的能力狀態(tài)機(jī)

3 SSRules 編程范式及其到HA 規(guī)則的翻譯

本節(jié)首先分析以狀態(tài)觸發(fā)器-狀態(tài)動(dòng)作(SS)風(fēng)格設(shè)計(jì)SSRules 編程范式的可行性;然后給出SSRules 提供給終端用戶使用的SS 規(guī)則范式的定義,分析它在應(yīng)對(duì)表2 所列的10 種TAP 缺陷的能力;接著分析轉(zhuǎn)譯器面對(duì)的主要問(wèn)題,并引入EE 中間范式作為SS 規(guī)則到HA 規(guī)則轉(zhuǎn)換的橋梁;最后介紹SS 到EE 轉(zhuǎn)譯的關(guān)鍵算法.

3.1 SS范式的引入

由第1 節(jié)可知:終端用戶不太能區(qū)分事件和狀態(tài),并且用戶使用State-State 時(shí)序范式會(huì)比使用含Event 觸發(fā)器的范式更易寫對(duì)規(guī)則.為此,我們以狀態(tài)為基礎(chǔ),通過(guò)規(guī)則分組、自動(dòng)優(yōu)先級(jí)等改進(jìn)措施(詳見(jiàn)第3.2 節(jié))來(lái)提供“State-trigger State-action”編程范式,簡(jiǎn)稱SS 范式.

? SS 范式的易寫易改性

SS 范式可以較為簡(jiǎn)潔地表達(dá)用戶日常常見(jiàn)需求;并且和Event-State→Event 相比,SS 范式寫出的規(guī)則容易隨需求的變更和細(xì)化進(jìn)行修改.為了更清晰地表述這兩種范式的區(qū)別,表5 給出了分別用兩種范式描述夜燈開(kāi)關(guān)的規(guī)則,其中,模式是HA 提供的虛擬傳感器,有回家模式和離家模式兩種取值.在SS 范式下,作用于夜燈的3條規(guī)則均作為子句按序置于“ FOR 夜燈”語(yǔ)句中,每個(gè)子句形如“EXPECT A [WHILE B]”,表示當(dāng)B 成立(或永真)時(shí),期望A 中各能力為指定的值;對(duì)于同一實(shí)體的多個(gè)EXPECT,SSRules 按從前往后以第一個(gè)WHILE 條件成立的EXPECT 子句所指定的期望狀態(tài)為準(zhǔn).然而,當(dāng)用Event-State→Event 表示時(shí),為了正確表達(dá)所列出的幾種情況的狀態(tài)保持和它們之間的轉(zhuǎn)移關(guān)系,需要寫出9 條規(guī)則來(lái)細(xì)分情況.假設(shè)用戶用SS 范式先寫了后2 條規(guī)則,運(yùn)轉(zhuǎn)一段時(shí)間后他又添加第1 條保證離家模式下夜燈總是關(guān)閉的需求,在SS 范式下,這種添加是簡(jiǎn)單的;但是若使用Event-State→Event 達(dá)到相同目的,則需要在原先第3 條~第6 條、第8 條、第9 條這6 條規(guī)則基礎(chǔ)之上新增3 條規(guī)則,并修改原先的規(guī)則細(xì)節(jié)(修改部分用粗體字表示),這樣的編寫和修改非?，嵥?、易錯(cuò).

Table 5 Example of comparing SS rules and Event-State→Event rules表5 SS 范式與Event-State→Event 范式的比較舉例

? SS 范式的局限

SS 范式能表達(dá)大多數(shù)智能家居的場(chǎng)景需求,但是無(wú)法表達(dá)無(wú)狀態(tài)或者難以抽象出狀態(tài)的事件和動(dòng)作(如無(wú)狀態(tài)按鈕、記錄日志等).對(duì)于這類需求,目前仍需編寫Event-State→Event 規(guī)則.因此,SSRules 將SS 范式轉(zhuǎn)譯為Event-State→Event,并允許兩種范式共存.未來(lái)可以擴(kuò)展降低這類需求編程難度的具體范式.

3.2 SS范式的定義

表6 的左部列出了SSRules 系統(tǒng)支持的SS 范式的抽象語(yǔ)法,其中:FOR 語(yǔ)句集結(jié)同一動(dòng)作實(shí)體的所有規(guī)則,且約定組內(nèi)靠前的規(guī)則優(yōu)先級(jí)更高;每條規(guī)則(ssrule)包含在WHILE 子句指定的條件成立時(shí),對(duì)該實(shí)體全部或部分能力的期望狀態(tài);多條規(guī)則按從前到后的次序、以第1 條滿足WHILE 條件的規(guī)則中的EXPECT 子句來(lái)設(shè)置期望的實(shí)體能力狀態(tài);一般地,無(wú) WHILE 子句的規(guī)則放在最后作為安全默認(rèn).Condition 中的“entityID.capName op value”,“historyOp timeperiod entityID.capName value”分別表示當(dāng)前狀態(tài)和歷史狀態(tài)型原子判斷,其中,歷史狀態(tài)運(yùn)算符historyOp 的4 種可能取值的含義舉例如下.

? “WITHIN 5 分鐘電扇.開(kāi)關(guān)關(guān)”表示電扇的開(kāi)關(guān)在5 分鐘內(nèi)曾經(jīng)處于關(guān)閉狀態(tài),則該原子判斷為真;

? “!WITHIN 5 分鐘電扇.開(kāi)關(guān)關(guān)”表示電扇的開(kāi)關(guān)在5 分鐘內(nèi)不曾處于關(guān)閉狀態(tài),則該原子判斷為真;

? “STAY 5 分鐘電扇.開(kāi)關(guān)開(kāi)”表示電扇的開(kāi)關(guān)在5 分鐘內(nèi)持續(xù)處于開(kāi)啟狀態(tài),則該原子判斷為真;

? “!STAY 5 分鐘電扇.開(kāi)關(guān)關(guān)”表示電扇的開(kāi)關(guān)在5 分鐘內(nèi)未一直處于開(kāi)啟狀態(tài),則該原子判斷為真.

Table 6 Abstract syntax of paradigms of SS rules and EE rules used in SSRules表6 SSRules 系統(tǒng)使用的SS 范式和EE 范式的抽象語(yǔ)法

3.3 SS范式的缺陷避免能力分析

SS 范式天然地排除了表2 中所列的缺陷⑨、缺陷⑩這兩種缺陷.對(duì)于在使用State-State 時(shí)序范式時(shí)可能存在的缺陷①~缺陷⑧這8 種缺陷,SS 范式的表示機(jī)制能完全避免缺陷①優(yōu)先級(jí)沖突;SS 范式的表示及轉(zhuǎn)譯機(jī)制能部分解決或消除缺陷②安全默認(rèn)偏差、缺陷③非瞬時(shí)動(dòng)作、缺陷⑥重復(fù)觸發(fā),其附帶效果可以輔助改善缺陷④缺少反向動(dòng)作;對(duì)于缺陷⑤無(wú)限循環(huán)、缺陷⑦不確定時(shí)序等缺陷的檢測(cè),可以通過(guò)模型檢查等方法在規(guī)則轉(zhuǎn)譯之前避免;由于難以提供通用的鑒別何謂矛盾的機(jī)制,因而SSRules 不能解決缺陷⑧矛盾的動(dòng)作.下面分別討論SS 范式應(yīng)對(duì)缺陷①~缺陷③和缺陷⑥的措施.

(1) “按動(dòng)作實(shí)體將規(guī)則分組、組內(nèi)規(guī)則有序”可完全避免缺陷①優(yōu)先級(jí)沖突

用戶只需移動(dòng)規(guī)則在組內(nèi)的相對(duì)位置,免除顯式設(shè)置優(yōu)先級(jí)數(shù)值的困難.由于同一動(dòng)作實(shí)體的各規(guī)則優(yōu)先級(jí)不同,故無(wú)缺陷①(示例見(jiàn)3.1 節(jié)).

(2) “將配置的安全默認(rèn)規(guī)則自動(dòng)作為動(dòng)作實(shí)體的最低優(yōu)先級(jí)規(guī)則”可輔助消除缺陷②安全默認(rèn)偏差

SSRules 提供可配的安全默認(rèn)設(shè)置文件,其中的條目形如“實(shí)體/實(shí)體類ssrule”可描述指定實(shí)體或?qū)嶓w類的默認(rèn)期望狀態(tài),SSRules 會(huì)自動(dòng)將其追加到相應(yīng)實(shí)體的規(guī)則集尾部,作為最低優(yōu)先級(jí)規(guī)則.例如針對(duì)門鎖可以配置默認(rèn)安全規(guī)則“EXPECT (狀態(tài),鎖定)”,則用戶只需描述其他需求,如:

FOR 門鎖 EXPECT (狀態(tài),未鎖定) WHILE 人體傳感器.狀態(tài)==激活 [AND 其他安全條件]

而SSRules 會(huì)自動(dòng)在尾部追加“EXPECT (狀態(tài),鎖定)”.只要人體傳感器不再激活,SSRules 就會(huì)按最后一條無(wú)條件子句的期望狀態(tài)將門鎖鎖定.這種做法消除缺陷②的前提是要正確配置安全默認(rèn)文件.

如果用戶希望在人體傳感器激活后2 分鐘內(nèi)均保持門鎖解鎖,可使用SS 范式提供的歷史狀態(tài)判斷:

FOR 門鎖 EXPECT (狀態(tài),未鎖定) WHILE WITHIN 2 分鐘人體傳感器.狀態(tài)激活 [AND 其他安全條件]

(3) “通過(guò)避免用戶直接編寫動(dòng)作”可避免缺陷③非瞬時(shí)動(dòng)作和缺陷⑥重復(fù)觸發(fā)

在SSRules 中,狀態(tài)轉(zhuǎn)移所需要的動(dòng)作的執(zhí)行前提被描述在實(shí)體-能力抽象信息中,用戶只能選擇期望的狀態(tài),而無(wú)法寫出有缺陷的程序造成對(duì)非瞬時(shí)動(dòng)作的多次觸發(fā)動(dòng)作而進(jìn)入不期望的狀態(tài).例如:針對(duì)沖泡咖啡這樣的非瞬時(shí)動(dòng)作,如果主人希望每天7:00 讓咖啡機(jī)工作,且咖啡機(jī)工作完成后自動(dòng)關(guān)閉,7:00~7:20 之外的時(shí)間不開(kāi)啟咖啡機(jī),則用SS 范式編寫的規(guī)則為:

FOR 咖啡機(jī)

EXPECT (開(kāi)關(guān),開(kāi)) WHILE 時(shí)鐘.時(shí)間>7:00 AND 時(shí)鐘.時(shí)間<7:20 AND 咖啡機(jī).咖啡狀態(tài)==未準(zhǔn)備好

EXPECT (開(kāi)關(guān),關(guān))

當(dāng)咖啡機(jī)開(kāi)啟后,即使咖啡未準(zhǔn)備好,SSRules 轉(zhuǎn)譯后的HA 規(guī)則也保證不會(huì)再出現(xiàn)開(kāi)啟動(dòng)作.而用戶倘若用State-State→Event 范式,容易寫出如下有缺陷的規(guī)則,造成咖啡機(jī)多次啟動(dòng):

IF 咖啡未準(zhǔn)備好 AND 時(shí)間處于7:00~7:20 之間 THEN 啟動(dòng)咖啡機(jī)

對(duì)于重復(fù)觸發(fā)缺陷,能夠用SS 范式表達(dá)的規(guī)則可以用上述類似的機(jī)制來(lái)避免;而不能夠用SS 范式表達(dá)的規(guī)則,仍需要使用Event-State→Event 或者Event-Event→Event 范式來(lái)寫(未來(lái)將對(duì)此提供更直觀的編程方式).

3.4 轉(zhuǎn)譯器面對(duì)的問(wèn)題及EE中間范式的引入

? 轉(zhuǎn)譯器面對(duì)的問(wèn)題

如果要在一個(gè)僅支持Event-State→Event 范式的智能家居系統(tǒng)上實(shí)現(xiàn)對(duì)SS 范式規(guī)則的支持,需要將智能家居系統(tǒng)狀態(tài)之間的轉(zhuǎn)移和狀態(tài)轉(zhuǎn)移帶來(lái)的新的狀態(tài)設(shè)定與智能家居系統(tǒng)所支持的事件和動(dòng)作關(guān)聯(lián)起來(lái),并且要盡可能避免重復(fù)觸發(fā)、非瞬時(shí)動(dòng)作等缺陷.這一翻譯過(guò)程應(yīng)該對(duì)用戶不可見(jiàn),是由系統(tǒng)自動(dòng)完成的.此外,為了從翻譯的主要算法中排除HA 規(guī)則描述的瑣碎細(xì)節(jié),以及讓算法一般化以支持到其他平臺(tái)的移植,SSRules 引入了EE 中間范式(基于Event-State→Event).從而:轉(zhuǎn)譯器的第1 階段,SS→EE 的翻譯可以避開(kāi)HA 的語(yǔ)法及實(shí)現(xiàn)細(xì)節(jié),重點(diǎn)是基于同一套實(shí)體-能力抽象將SS 范式表示的功能需求轉(zhuǎn)化為EE 范式所表示的具體做法;而第2 階段,EE→HA 的翻譯則只需從較為抽象的EE 規(guī)則根據(jù)HA 的事件/條件描述方式、動(dòng)作對(duì)應(yīng)表,生成HA 所需的規(guī)則細(xì)節(jié)即可.

? EE 中間范式

表6 的右部列出了SSRules 系統(tǒng)轉(zhuǎn)譯中使用的EE 中間范式的抽象語(yǔ)法,其主要特點(diǎn)為:一條規(guī)則可以含有多個(gè)觸發(fā)事件(event)、條件過(guò)濾(condition)和多個(gè)按順序執(zhí)行的動(dòng)作(eeAction).event 包括狀態(tài)值變化事件“entityID.capName FROM range TO range”和狀態(tài)保持事件“entityID.capName STAYON value REACH timeperiod”:前者表示給定實(shí)體能力的取值從一個(gè)值集變遷到另一個(gè)值集,后者表示指定的實(shí)體能力保持給定值value 的時(shí)間長(zhǎng)達(dá)timeperiod 時(shí)觸發(fā)該事件.目前,SSRules 僅對(duì)二值類型的能力提供狀態(tài)保持事件.EE 范式中條件過(guò)濾condition 的定義與SS 范式一樣.

? EE 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯

EE 規(guī)則到HA 規(guī)則的翻譯是一一對(duì)應(yīng)的,EE 規(guī)則的狀態(tài)值變化事件可以對(duì)應(yīng)到HA 的state_changed 事件和在HA 規(guī)則的condition 中對(duì)事件數(shù)據(jù)中的old_state 和new_state 的限制條件.EE 規(guī)則中的狀態(tài)保持事件可以轉(zhuǎn)譯為在HA 中的延時(shí)執(zhí)行和自定義事件觸發(fā).EE 規(guī)則中的條件表達(dá)式可以對(duì)應(yīng)到HA 條件表達(dá)式中的相同樹(shù)形結(jié)構(gòu).EE 規(guī)則中,實(shí)體能力的取值對(duì)應(yīng)到HA 規(guī)則中的狀態(tài)對(duì)象state 或者狀態(tài)對(duì)象attribute 中的附加狀態(tài);EE 規(guī)則中,對(duì)實(shí)體能力的歷史狀態(tài)判斷被對(duì)應(yīng)到HA 規(guī)則中的自定義狀態(tài)對(duì)象取值判斷;EE 規(guī)則中的一個(gè)或多個(gè)動(dòng)作被單個(gè)或組合對(duì)應(yīng)到HA 中無(wú)參或帶參的服務(wù)調(diào)用.

3.5 SS規(guī)則集與EE規(guī)則集的符號(hào)表示與一些定義

為了方便后文的說(shuō)明和理解,我們引入表7 中的符號(hào)以及幾個(gè)基本概念,這些符號(hào)和表6 定義的語(yǔ)法結(jié)構(gòu) 一一對(duì)應(yīng).例如:GS對(duì)應(yīng)于語(yǔ)法定義中的一個(gè)ssrulesGroup,RS對(duì)應(yīng)于一個(gè)ssrule,RS中的C和X分別對(duì)應(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ī)則集合的符號(hào)表示

對(duì)于一個(gè)由ND個(gè)實(shí)體組成的智能家居系統(tǒng),每個(gè)由三元組(e,C,M)描述.在某個(gè)時(shí)刻下,W的系統(tǒng)狀態(tài)記為σ,它是各實(shí)體的各能力到狀態(tài)值的映射,即σ(e,c)表示實(shí)體e的能力c 在該時(shí)刻的狀態(tài)值.不論是SS 范式的程序GS,還是EE 范式的程序RE,都是對(duì)系統(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)).對(duì)于規(guī)則引擎來(lái)說(shuō),系統(tǒng)當(dāng)前狀態(tài)σ、當(dāng)前時(shí)刻τnow以及狀態(tài)變化軌跡T可抽象為一個(gè)三元組ω=(σ,τnow,T),稱之為系統(tǒng)抽象狀態(tài).其中,T=((e1,c1,v1,τ1),,…,(en,cn,vn,τn)),(ei,ci,vi,τi)表示實(shí)體ei的能力ci在τi時(shí)刻變?yōu)関i(i∈{1,…,n}),它只記錄狀態(tài)值發(fā)生變化的特定實(shí)體的特定能力及其新?tīng)顟B(tài).狀態(tài)變化可能由外 部事件引起(如用戶交互、環(huán)境變化),也可能由GS或RE執(zhí)行動(dòng)作序列引起.每當(dāng)發(fā)生狀態(tài)變遷時(shí),都相當(dāng)于T更新為,其中,τn+1為狀態(tài)變遷發(fā)生時(shí)的τnow.

定義2(規(guī)則在系統(tǒng)抽象狀態(tài)ω下激活).假設(shè)GS=(e,RS)為某動(dòng)作實(shí)體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ī)則的條件(對(duì)應(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ī)則.

實(shí)際的規(guī)則引擎提供的時(shí)間戳的精度是有限的.假設(shè)系統(tǒng)抽象狀態(tài)ω中的時(shí)間戳都有最小時(shí)間單位(例如1秒),τnow以最小時(shí)間單位離散地更新.那么,對(duì)于規(guī)則集合執(zhí)行方式的假設(shè)如下.

? SS 規(guī)則執(zhí)行假設(shè).假設(shè)無(wú)時(shí)序缺陷的規(guī)則組GS的執(zhí)行方式為:每當(dāng)發(fā)生狀態(tài)變化,或者τnow變?yōu)樾轮抵?判斷GS中是否存在與最新的ω不兼容的規(guī)則.如果存在這樣的規(guī)則RS,說(shuō)明其對(duì)應(yīng)實(shí)體e不滿足RS的期望狀態(tài)組X,于是計(jì)算e上的需要執(zhí)行的動(dòng)作序列A,使得A執(zhí)行后實(shí)體e的狀態(tài)符合X;

? EE 規(guī)則執(zhí)行假設(shè).假設(shè)無(wú)時(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中的某個(gè)狀態(tài)保持事件后,檢查與觸發(fā)事件相符的各條規(guī)則.如果存在RE,RS.C在ω下成立,則執(zhí)行 RE.A.

定義4(SS 與EE 的一致性).稱GS與RE一致是指:對(duì)于無(wú)時(shí)序缺陷的GS,RE,在上述規(guī)則執(zhí)行假設(shè)下(且不存在超時(shí)、執(zhí)行失敗、規(guī)則重疊執(zhí)行的情形),從與GS兼容的任意系統(tǒng)抽象狀態(tài)ω開(kāi)始,對(duì)于同樣的、同時(shí)刻的、一次發(fā)生一個(gè)事件的外部事件序列,GS所產(chǎn)生的狀態(tài)變遷序列和RE所產(chǎn)生的狀態(tài)變遷序列一致.

與GS一致的RE不唯一,原因在于:① RE中不會(huì)被執(zhí)行的規(guī)則不影響一致性;② 一個(gè)條件較弱的EE 規(guī)則(如一條規(guī)則,條件.C為時(shí)鐘.狀態(tài)==白天)可等價(jià)于多個(gè)條件更強(qiáng)的EE 規(guī)則(如等價(jià)于規(guī)則和,條件.C和.C分別為“時(shí)鐘.狀態(tài)==白天 AND 模式.狀態(tài)==回家模式”和“時(shí)鐘.狀態(tài)==白天 AND 模式.狀態(tài)==離家模式”);③ 一條EE 規(guī)則RE還可以等價(jià)于m條EE 規(guī)則,滿足.E ;④ 邏輯表達(dá)式 有多種等價(jià)表述.

3.6 SS規(guī)則到EE規(guī)則的轉(zhuǎn)譯

圖3 詳細(xì)說(shuō)明了SS 規(guī)則到EE 規(guī)則的轉(zhuǎn)譯算法實(shí)現(xiàn),其中:圖3(a)中的算法1 是總控算法;圖3(b)是相應(yīng)的 流程圖,轉(zhuǎn)譯器的輸入分別是左上角的實(shí)體-能力抽象信息W和右上角的SS 規(guī)則集合GS,輸出是與輸入SS 規(guī)則集對(duì)應(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ī)則集解析器首先會(huì)解析用戶輸入的GS,并將解析結(jié)果傳給動(dòng)作序列信息生成模塊;

? 然后,動(dòng)作序列信息生成模塊會(huì)將同一動(dòng)作實(shí)體e的SS 規(guī)則序列GS=(e,RS)按照EXPECT 子句作用的期望狀態(tài)組分類,期望狀態(tài)組X相同的SS 規(guī)則組中的多條規(guī)則會(huì)放在一起處理:一方面,調(diào)用ConditionalActionsPairs(e,X,W)(見(jiàn)算法2),計(jì)算實(shí)體e上所有可能的動(dòng)作序列Aj和每種動(dòng)作序列的執(zhí)行前提Cj,得到二元組集合PairsX={(Cj,Aj) |j∈{1,n}};另一方面,求出與規(guī)則組不兼容的條件ΨX(見(jiàn)算法1 第5 行),這是事件發(fā)生后、動(dòng)作執(zhí)行前系統(tǒng)抽象狀態(tài)所應(yīng)滿足的條件;

? 接下來(lái),事件篩選模塊首先調(diào)用CandidateEvents(ΨX,W)(見(jiàn)算法3),根據(jù)ΨX生成一組候選事件E(這些事件可能對(duì)ΨX的成立與否有影響);然后,對(duì)E中的每個(gè)事件E調(diào)用ShouldRejectEvent(E,ΨX,W)(見(jiàn)算法4),依據(jù)缺省的事件篩選策略Pdefault判斷該事件是否要排除掉,即:若E發(fā)生后ΨX不成立,則需將E排除;

在轉(zhuǎn)譯過(guò)程中,有多個(gè)環(huán)節(jié)需要與Z3 交互:在轉(zhuǎn)譯開(kāi)始之前,轉(zhuǎn)譯器會(huì)根據(jù)實(shí)體-能力抽象構(gòu)建Z3 數(shù)據(jù)類型和Z3 常量,并將對(duì)應(yīng)關(guān)系填入Z3-Python 數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換模塊中的Z3 常量映射表;在轉(zhuǎn)譯過(guò)程中,事件篩選模塊和EE 中間表示生成模塊通過(guò)Z3 判定事件的可滿足性;規(guī)則合并模塊通過(guò)Z3 判斷等價(jià)的條件部分,合并觸發(fā)事件;可讀性化簡(jiǎn)模塊通過(guò)Z3 進(jìn)行表達(dá)式化簡(jiǎn)以減少條件表達(dá)式長(zhǎng)度.

下面結(jié)合算法2~算法5 詳細(xì)介紹動(dòng)作序列信息生成、事件篩選以及EE 中間表示生成這3 個(gè)關(guān)鍵模塊.

算法2.“執(zhí)行前提-動(dòng)作序列”對(duì)集合的生成(ConditionalActionsPairs).

輸入:實(shí)體e,期望狀態(tài)組X,系統(tǒng)實(shí)體-能力抽象W;

輸出:結(jié)構(gòu)如{(C1,A1),…,(Cn,An)}的Pairs,表示實(shí)體e 滿足Ci時(shí)要達(dá)到X需執(zhí)行Ai.

? 動(dòng)作序列信息生成模塊

該模塊會(huì)針對(duì)期望狀態(tài)組X相同的SS 規(guī)則組,調(diào)用算法2 產(chǎn)生可能的動(dòng)作序列及其執(zhí)行前提集合PairsX={(Cj,Aj) |j∈{1,n}},并求出與不兼容的條件ΨX(見(jiàn)算法1 第5 行).算法2 的第2 行指出,X投影得到的能力集合XC 中的每個(gè)能力都必須是可控的.如第2.4 節(jié)所述,可控能力c 的狀態(tài)機(jī)Mc=(Vc,Tc)中的轉(zhuǎn)移函數(shù),每個(gè)狀態(tài)轉(zhuǎn)移帶有條件C以及要執(zhí)行的命令J,C中可能會(huì)涉及其他實(shí)體能力.考慮到實(shí)際需求以及處理上的簡(jiǎn)便,假設(shè)XC 中各能力的狀態(tài)轉(zhuǎn)移條件C中依賴的其他能力遵循部分序關(guān)系,算法2 的第3行調(diào)用Reorder 函數(shù)將XC 中的能力按這種序關(guān)系重排得到,這樣在第8 行就可以嘗試按此順序依次檢查動(dòng)作轉(zhuǎn)移的可行性.另外,對(duì)于中的能力ci,其狀態(tài)值域可能是無(wú)限的實(shí)數(shù),而是有限的,故第5 行的SplitRangeByAction 函數(shù)會(huì)檢查中到達(dá)期望值vi的各個(gè)狀態(tài)轉(zhuǎn)移動(dòng)作J和轉(zhuǎn)移條件C,將J,C相同的狀態(tài)轉(zhuǎn)移的起始狀態(tài)涉及的各狀態(tài)值劃分到同一個(gè)子集,從而形成的有限子集劃分Setsi,進(jìn)而可能減少第7 行要處理的初始狀態(tài)情形的數(shù)目,也能夠減少后續(xù)規(guī)則合并的運(yùn)算次數(shù).

下面結(jié)合圖4 的例子來(lái)解釋.該例子的動(dòng)作實(shí)體為“電扇”,有3 條SS 規(guī)則.這些規(guī)則按期望狀態(tài)組X是否相同分成兩組.以組為例,根據(jù)該組的X2“(開(kāi)關(guān),開(kāi))(風(fēng)速,低)”和圖2 電扇的狀態(tài)機(jī),按照算法2 求出到達(dá)X2的所有執(zhí)行前提-動(dòng)作序列對(duì)(圖4 左下方的4 種動(dòng)作序列).另一方面,該模塊也要輸出不兼容的條件用于稍后的事件篩選,=模式.狀態(tài)==回家模式 AND 溫濕度傳感器.溫度 >28°C AND (電扇.開(kāi)關(guān)!=開(kāi)OR 電扇.風(fēng)速!=低).

Fig.4 Generating sequences of commands information圖4 動(dòng)作序列信息生成

? 事件篩選模塊

該模塊先使用算法3 生成候選事件,接著進(jìn)一步使用算法4,根據(jù)系統(tǒng)可能的狀態(tài)變遷對(duì)事件進(jìn)行篩選.算法3 主要根據(jù)一個(gè)執(zhí)行前要滿足的條件C生成候選事件集,旨在以較低運(yùn)算成本快速得到較小的待篩選事件集.其中:第2 行分別獲取C中出現(xiàn)的實(shí)體能力集合ECs以及原子條件集合Catom,原子條件有當(dāng)前狀態(tài)判斷(e,c,O,v)和歷史狀態(tài)判斷(e,c,Oh,t,v)這兩種形式(如表7);第4 行的SplitRangeByCond 則是根據(jù)Catom對(duì)實(shí)體E的能力 c 的狀態(tài)值域Vc進(jìn)行劃分,將對(duì)所有原子條件的判斷影響一致的狀態(tài)取值劃分到同一個(gè)子集,從而將實(shí)數(shù)類型的事件轉(zhuǎn)移轉(zhuǎn)化為了有限情形;第5 行~第7 行分別產(chǎn)生狀態(tài)變化事件El和狀態(tài)保持事件EH,能夠涵蓋C中出現(xiàn)的原子條件取值變化的情形.對(duì)于歷史狀態(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)遷移中快速知道實(shí)體能力保 持狀態(tài)的時(shí)長(zhǎng),再結(jié)合C中的Oh進(jìn)行狀態(tài)保持的可滿足性檢查.

算法3.候選事件生成算法(CandidateEvents).

算法4.事件排除判定算法(ShouldRejectEvent).

算法5.同一動(dòng)作序列的EE 規(guī)則生成(SameActionsRules).

算法4 旨在判斷事件E可否發(fā)生并在發(fā)生后使得Ψ(不兼容的條件)為真(進(jìn)而導(dǎo)致Ψ對(duì)應(yīng)的某個(gè)動(dòng)作序列的執(zhí)行),需要根據(jù)篩選策略P做關(guān)于系統(tǒng)抽象狀態(tài)的可滿足性判定.篩選策略從保守到激進(jìn)有多種策略:激進(jìn) 的策略需要對(duì)事件發(fā)生之前的系統(tǒng)狀態(tài)做出更強(qiáng)的假設(shè),而保守的策略只需要相對(duì)較弱、能夠更快判定的假 設(shè).本文提出的默認(rèn)策略Pdefault為:事件發(fā)生前Ψ為假(兼容),事件發(fā)生后Ψ為真(不兼容),且事件發(fā)生前 后Vs→Vd的事件轉(zhuǎn)移條件CE成立,則該事件不會(huì)被排除.

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ī) 則組的不兼容條件為例,對(duì)于圖4 左下方中的4 個(gè)執(zhí)行前提-動(dòng)作序列對(duì),都要判斷執(zhí)行前提是否可能 滿足并生成規(guī)則.這里以4 對(duì)中的左上一對(duì)為例,由算法5 的第5 行得到的條件:“回家模式=回家模式 AND 溫濕度傳感器.溫度>28°C AND (電扇.開(kāi)關(guān)!=開(kāi) OR 電扇.風(fēng)速!=低) AND (電扇.開(kāi)關(guān)!=開(kāi) AND 電扇.風(fēng)速!=低)”作為動(dòng)作執(zhí)行的完整前提條件,同時(shí)也應(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

電扇.開(kāi)關(guān)!=開(kāi) AND 電扇.風(fēng)速!=低 THEN 電扇.開(kāi)關(guān) 打開(kāi),電扇.風(fēng)速 設(shè)定 低.

算法4 雖然和這里的算法5 都需要對(duì)一組系統(tǒng)狀態(tài)的斷言做可滿足性求解,但是算法4 不考慮動(dòng)作序列的 執(zhí)行前提,其篩選結(jié)果能夠被同一X的多個(gè)動(dòng)作序列復(fù)用;且能夠通過(guò)算法4 篩選的只有較少數(shù)量事件,這些事 件至少能夠與一個(gè)動(dòng)作序列組合成為規(guī)則.算法4 的存在,減少了轉(zhuǎn)譯過(guò)程中總的可滿足性判定的次數(shù).若直接將候選事件集合與多種動(dòng)作序列的組合輸入算法5,可能需要較多次數(shù)的不必要的求解.

4 方法評(píng)估

為了驗(yàn)證SSRules 的系統(tǒng)設(shè)計(jì)的有效性,基于Python 開(kāi)發(fā)了SSRules 運(yùn)行時(shí)子系統(tǒng)和離線轉(zhuǎn)譯器;基于Javascript 開(kāi)發(fā)了SSRules 前端用戶交互模塊,方便終端用戶設(shè)置SS 規(guī)則(如圖6 左上方);同時(shí),結(jié)合已有用戶調(diào)查[15]構(gòu)建智能家居使用情景,在這些場(chǎng)景下,就SSRules 系統(tǒng)運(yùn)行情況和規(guī)則轉(zhuǎn)譯效果進(jìn)行評(píng)估和討論.

4.1 智能家居實(shí)驗(yàn)場(chǎng)景搭建

為了能夠評(píng)估SSRules,需要將一些設(shè)備連接到HA,并讓設(shè)備和環(huán)境產(chǎn)生足夠多的狀態(tài)轉(zhuǎn)移,以覆蓋各種可能的使用情形.但是,使用真實(shí)設(shè)備無(wú)法在短時(shí)間得到這樣的測(cè)試場(chǎng)景并且調(diào)試不便.為此,我們基于Unity 游戲引擎開(kāi)發(fā)了一個(gè)能接入HA 的智能家居模擬器HA-Simulator(其界面如圖6 下方).利用HA-Simulator 可以將時(shí)間加速,以較高的速度發(fā)生系統(tǒng)的狀態(tài)變化,并對(duì)溫濕度/煙霧濃度等環(huán)境因素合理建模.這使得在短時(shí)間內(nèi)測(cè)試大量的智能家居系統(tǒng)狀態(tài)變遷并驗(yàn)證SSRules 成為可能.

在HA-Simulator 中模擬了12 種智能家居設(shè)備,布局和類型如圖6 右上方所示,這些設(shè)備通過(guò)HA 的MQTT Discovery 集成方式接入HA.此外,在HA 中以自定義方式提供模式、天氣和時(shí)鐘這3 種虛擬設(shè)備.在模擬器中,同一房間內(nèi)的設(shè)備受同一組環(huán)境變量(溫度、濕度、煙霧濃度)的影響.模擬器可以設(shè)置環(huán)境變量改變的速度,進(jìn)而間接改變虛擬傳感器的取值;同時(shí),模擬器中的設(shè)備可以被手動(dòng)調(diào)節(jié)或者由模糊測(cè)試程序隨機(jī)改變.

Fig.6 SSRules user interface,Smart home configuration and HA-simulator圖6 SSRules 用戶交互界面與智能家居場(chǎng)景配置和模擬器示意圖

4.2 實(shí)驗(yàn)結(jié)果分析

? SS→HA 翻譯對(duì)比

首先參考以往用戶調(diào)查[15]中用戶的智能家居需求,構(gòu)造了10 組SS 規(guī)則作為測(cè)試集,其中:編號(hào)為1~6 的規(guī)則組不含歷史狀態(tài),編號(hào)為T1~T4 的規(guī)則組含有歷史狀態(tài).每一組規(guī)則至少有一個(gè)動(dòng)作實(shí)體(設(shè)備),規(guī)則中會(huì)引用多個(gè)相關(guān)實(shí)體的狀態(tài).另外,規(guī)則組6、規(guī)則組T3、規(guī)則組T4 含有多個(gè)動(dòng)作實(shí)體.按照當(dāng)前的事件篩選策略,翻譯前后的規(guī)則條數(shù)比較見(jiàn)表8.最終生成的HA 規(guī)則條數(shù)均多于SS 規(guī)則條數(shù),比例為2 倍~4 倍.

? HA 規(guī)則運(yùn)行覆蓋率

在由SS 轉(zhuǎn)譯得到HA 規(guī)則之后,每一組HA 規(guī)則均在模擬器上運(yùn)行20 分鐘.除第1 組規(guī)則(包含空調(diào)與溫濕度傳感器)和第3 組規(guī)則(包含排氣扇以及其他4 個(gè)相關(guān)實(shí)體)之外,其余組的HA 規(guī)則均全部被執(zhí)行過(guò).這說(shuō)明SS→HA 轉(zhuǎn)譯器為其余8 組規(guī)則產(chǎn)生的HA 規(guī)則集中沒(méi)有多余的規(guī)則,當(dāng)前的事件篩選策略對(duì)于多數(shù)測(cè)試樣例是比較合理的.對(duì)于含有多余規(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ī)則中,沒(méi)有被執(zhí)行過(guò)的(可能是多余的)一條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 翻譯對(duì)比和測(cè)試運(yùn)行

原因在于:當(dāng)前的篩選策略沒(méi)有假設(shè)系統(tǒng)狀態(tài)在事件發(fā)生之前的瞬間與整個(gè)規(guī)則組GS的描述相符,而僅僅假設(shè)系統(tǒng)狀態(tài)與第3 條SS 規(guī)則的描述是兼容的(即第3 條規(guī)則未激活或者其期望狀態(tài)已滿足).但是在測(cè)試運(yùn)行中,當(dāng)溫度低于10°C 或者高于28°C 時(shí),系統(tǒng)狀態(tài)持續(xù)與GS的描述相符,空調(diào)模式一定是制熱(第2 條SS 規(guī)則激活)或者制冷(第1 條SS 規(guī)則激活),所以該條EE 規(guī)則是多余的,通過(guò)使用更激進(jìn)的事件篩選策略可將其消除.

? HA 規(guī)則運(yùn)行異常檢測(cè)

表8 的后3 列分別是在20 分鐘的隨機(jī)測(cè)試下,各組的HA 規(guī)則的執(zhí)行次數(shù)、異常檢測(cè)模塊發(fā)現(xiàn)的異常次數(shù)(系統(tǒng)狀態(tài)不滿足動(dòng)作實(shí)體的SS 規(guī)則集合中激活的那一條SS 規(guī)則的期望狀態(tài))與總檢測(cè)次數(shù)之比、是否存在連續(xù)兩次檢測(cè)到異常的情況.各組總的規(guī)則執(zhí)行次數(shù)相差不大.異常檢測(cè)模塊目前以定時(shí)輪詢方式實(shí)現(xiàn),在20分鐘內(nèi)進(jìn)行了1 200 次異常檢查,未發(fā)現(xiàn)連續(xù)出現(xiàn)異常的情形.對(duì)于單次檢測(cè)出現(xiàn)異常的情況,經(jīng)過(guò)查看記錄的狀態(tài)日志和HA 規(guī)則的執(zhí)行序列,這些異常均因網(wǎng)絡(luò)延遲(動(dòng)作執(zhí)行不及時(shí))造成.

5 相關(guān)工作

智能家居目前在市場(chǎng)上受到了廣泛歡迎,越來(lái)越多的家庭配置了智能家居的設(shè)備.智能家居最吸引人的功能之一就是以應(yīng)用程序的形式支持自定義自動(dòng)化.但是由于用戶未經(jīng)過(guò)專業(yè)的培訓(xùn),導(dǎo)致其自定義的規(guī)則存在一定的缺陷,甚至無(wú)法定制規(guī)則,這引起了人們對(duì)物聯(lián)網(wǎng)增強(qiáng)生活的風(fēng)險(xiǎn)的擔(dān)憂.這些風(fēng)險(xiǎn)遠(yuǎn)非僅僅是學(xué)術(shù)上的,更緊迫的是對(duì)用戶的生命財(cái)產(chǎn)的威脅.Triger-Action 編程(TAP)是一種流行的終端用戶編程方式,可以讓用戶實(shí)現(xiàn)其智能設(shè)備和云服務(wù)的交互.然而,用戶有時(shí)并不能通過(guò)TAP 正確表達(dá)自己的意圖并實(shí)現(xiàn)相應(yīng)的功能.隨著此類系統(tǒng)部署在越來(lái)越復(fù)雜的智慧家居場(chǎng)景中,用戶必須能夠識(shí)別編程錯(cuò)誤并解決.

為了給終端用戶提供更高效的服務(wù),首先需要理解用戶編程出現(xiàn)錯(cuò)誤和規(guī)則沖突的原因.Huang 等人[6]認(rèn)為,現(xiàn)有TAP 編程系統(tǒng)(如IFTTT)的過(guò)分簡(jiǎn)化限制了程序的表達(dá)能力.提出了改進(jìn)IFTTT 界面的建議,以減輕因心理模型不正確而引起的問(wèn)題.Corno 等人[28]認(rèn)為:現(xiàn)有的TAP 接口界面暴露了太多功能,并迫使用戶在眾多混亂的網(wǎng)格菜單中進(jìn)行搜索,導(dǎo)致用戶無(wú)法得到原本需要的功能.為此,作者提出了EUDoptimizer,旨在以交互方式協(xié)助終端用戶使用循環(huán)中的優(yōu)化器來(lái)組合 IF-THEN 規(guī)則,減少了編寫Triger-Action 規(guī)則所需的工作.Brackenbury 等人[17]提出了10 類常見(jiàn)的TAP 編程錯(cuò)誤類型,作者發(fā)現(xiàn):錯(cuò)誤的存在,使參與者更難正確預(yù)測(cè)規(guī)則的行為.Davidoff 等人[29]發(fā)現(xiàn),智能家居用戶的日?；顒?dòng)與編程任務(wù)并不匹配.論文描述了家庭想要的控制,并提出了有助于終端用戶編程系統(tǒng)實(shí)現(xiàn)這種控制的7 種設(shè)計(jì)原則.Brush 等人[20]認(rèn)為:為使智能家居得到更廣泛的使用,需要解決成本高昂、設(shè)備不靈活、客觀理性差和安全保障這4 個(gè)障礙.論文還為進(jìn)一步研究提供了幾個(gè)方向,包括消除變化結(jié)構(gòu)的需要、為用戶提供簡(jiǎn)單的安全原語(yǔ)并支持家庭設(shè)備的組合.

因此,為減少終端用戶編程的錯(cuò)誤,TAP平臺(tái)需要對(duì)用戶生成TAP規(guī)則進(jìn)行指導(dǎo),并實(shí)現(xiàn)模型的檢查,自動(dòng)發(fā)現(xiàn)規(guī)則漏洞或沖突.Wang 等人[14]利用IFTTT 平臺(tái),探討了在Triger-Action 平臺(tái)中可能存在的規(guī)則漏洞,并借助于自然語(yǔ)言處理的方法推斷Triger-Action 信息,實(shí)現(xiàn)了一個(gè)模型檢查系統(tǒng)iRuler,用于發(fā)現(xiàn)物聯(lián)網(wǎng)中的規(guī)則間漏洞.Celik 等人[19,30,31]認(rèn)為,物聯(lián)網(wǎng)中存在大量的設(shè)備交互.因此,不僅需要驗(yàn)證單個(gè)設(shè)備,還需要對(duì)設(shè)備的聯(lián)合行為進(jìn)行檢查.Soteria[30]是一種靜態(tài)分析系統(tǒng),可從IoT 應(yīng)用程序的源代碼中提取狀態(tài)模型,并通過(guò)模型檢查來(lái)驗(yàn)證IoT 應(yīng)用程序或IoT 環(huán)境是否符合已標(biāo)識(shí)的屬性.考慮到靜態(tài)分析在估計(jì)物聯(lián)網(wǎng)狀態(tài)轉(zhuǎn)換方面的局限性,Celik 等人[19]繼續(xù)開(kāi)發(fā)了一個(gè)動(dòng)態(tài)分析系統(tǒng)IoTGuard,可通過(guò)在運(yùn)行時(shí)監(jiān)視設(shè)備執(zhí)行行為,來(lái)強(qiáng)制執(zhí)行已標(biāo)識(shí)的屬性,并可以通過(guò)阻止違反屬性的設(shè)備操作,或在運(yùn)行時(shí)要求用戶批準(zhǔn)或拒絕違規(guī)操作來(lái)應(yīng)對(duì)屬性違規(guī).肖丁等人提出的基于知識(shí)圖譜的KGIID 算法[32]能夠檢測(cè)TAP 編程模型中沖突的動(dòng)作(隱式?jīng)_突).孟巖等人提出的HODETECT 檢測(cè)工具[33]利用無(wú)線側(cè)信道技術(shù)從智能家居應(yīng)用中提取工作邏輯,并用有限狀態(tài)自動(dòng)機(jī)建模,通過(guò)在應(yīng)用運(yùn)行時(shí)監(jiān)聽(tīng)無(wú)線加密流量的元數(shù)據(jù)來(lái)推測(cè)應(yīng)用的執(zhí)行狀態(tài),間接檢測(cè)惡意應(yīng)用.陳星等人[34]提出了智能家居情境感知服務(wù)的運(yùn)行時(shí)建模與執(zhí)行方法,能夠降低開(kāi)發(fā)者開(kāi)發(fā)智能家居情境感知服務(wù)的難度和復(fù)雜度.

更進(jìn)一步地,TAP 服務(wù)提供平臺(tái)還需要對(duì)存在缺陷的規(guī)則進(jìn)行修復(fù).Nandi 等人[26]注意到,終端用戶在編寫規(guī)則時(shí)所犯的一個(gè)常見(jiàn)錯(cuò)誤是觸發(fā)器數(shù)量不足.因此,作者開(kāi)發(fā)了TrigGen,它可以根據(jù)規(guī)則中的操作自動(dòng)生成一組必要和充分的觸發(fā)器,來(lái)幫助終端用戶正確地編寫規(guī)則.這種做法在一定程度上減少了意外行為和安全漏洞的發(fā)生率,但是其對(duì)于潛在沖突的檢測(cè)還有提升空間.為幫助非專業(yè)的物聯(lián)網(wǎng)用戶系統(tǒng)地實(shí)現(xiàn)高置信度的實(shí)時(shí)HA-IoT 系統(tǒng),Bu 等人[16]介紹了一種自動(dòng)化端到端編程輔助框架MenShen,它能夠檢查自動(dòng)化規(guī)則集是否違反規(guī)范,從而為用戶提供可能的解決方案.Zave 等人[24]建議在運(yùn)行時(shí)通過(guò)優(yōu)先級(jí)來(lái)減少設(shè)備管理和交互的成本,并通過(guò)組合機(jī)制實(shí)現(xiàn)了目標(biāo).Zhang等人[15]將用戶需要表達(dá)的屬性轉(zhuǎn)換為線性時(shí)序邏輯(LTL),自動(dòng)合成滿足屬性的TAP 規(guī)則,并修復(fù)現(xiàn)有的TAP 規(guī)則.

6 總 結(jié)

基于規(guī)則的智能家居系統(tǒng)是目前流行的一種智能家居系統(tǒng),而編寫瑣碎、修改困難、錯(cuò)誤難以追蹤是以往用戶調(diào)查[15]所反映的問(wèn)題.本文提出的SS 范式以及配套的SSRules 系統(tǒng)實(shí)現(xiàn)方式,使得用戶規(guī)則編寫和修改的復(fù)雜程度大為減低;同時(shí),設(shè)計(jì)的SS 規(guī)則到HA 規(guī)則的轉(zhuǎn)譯算法使得輸入的SS 規(guī)則能夠在現(xiàn)有的智能家居系統(tǒng)HA 規(guī)則引擎上運(yùn)行,并且通過(guò)輔助的SSRules 運(yùn)行時(shí)模塊,能夠提供規(guī)則執(zhí)行異常檢測(cè)的能力.

未來(lái)的工作重點(diǎn)在以下兩個(gè)方面:一方面,采用模型檢測(cè)技術(shù)實(shí)現(xiàn)對(duì)SS 范式無(wú)法避免的缺陷進(jìn)行檢測(cè),并設(shè)計(jì)輔助用戶編寫SS 規(guī)則和避免缺陷的實(shí)時(shí)反饋算法;另一方面,對(duì)于SS 范式目前不能夠表達(dá)的需求,進(jìn)行用戶調(diào)查并尋找合適的多范式協(xié)同輸入對(duì)策.