CN106055318B - 一种智能家居物联网系统验证与修复的方法和装置 - Google Patents

Abstract

本发明公开了一种智能家居物联网系统验证与修复的方法和装置。本发明通过智能家居设备描述信息和IFTTT规则构建混成自动机模型，然后通过对混成自动机模型的路径分析，找出可能到达系统不安全的路径，然后将这些可达路径编码成SMT约束进行求解，如果存在可达路径对应的SMT约束可解，则根据可解的SMT约束对IFTTT规则This部分中实数型条件值进行修正。修正的方法是通过将可解的SMT约束中的对应的IFTTT规则This部分中实数型条件值参数化后并将整个SMT约束取反，然后消去量词后进行求解，将可解值替换This部分中实数型条件值。

Description

一种智能家居物联网系统验证与修复的方法和装置

技术领域

本发明涉及智能家居物联网系统中IFFF规则的校验和修复。

背景技术

近来，智能家居设备的出现以及趋向普及。随着智能家居设备的数目与种类的增多，出现了能够把智能家居设备连接起来完成更为复杂的操作的IFTTT(IF THIS THENTHAT)规则，具体表现为IF设备中某变量取值达到某条件(THIS)，THEN执行另一个设备中某操作(THAT)。IFTTT就是根据规定的规则，当某个智能家居设备发生某些事件时，触发另一个设备进行某种操作。

这种趋势由于能够更好的连系多种智能家居设备并满足用户复杂的要求，能够让每个用户都能够参与编写自己规则的方法，受到广泛的关注。它具有的优越性主要在于能够使智能设备不再单独存在，而是连系成为一个系统网络，能够完成的任务更为复杂和实用。同时，通过很简单的方法，每个用户都可以在没有专业知识的情况下，编写和使用自己的规则，根据自己的日常行为习惯调整系统。目前，已经有了大量的设备厂商支持这种技术，并具有大量的用户。

然而，在这种技术出现的同时，也引起了一些安全隐患。智能设备种类繁多，组合方式难以预料，现有的方法难以对其进行系统性验证或测试。同时，用户自定义规则带来规则的多样性和随意性，系统行为难以预料，不能保证系统的安全性。并且，由于智能家居设备具有实时性特征，设备行为与时间息息相关，更增大了系统的复杂性，对安全性检验是很大的考验。而尽管有着这些安全隐患，普通用户对相关信息毫无意识，并不知道自己所构建的系统存在危险的可能，因此，为相关系统的安全性给出系统性检查与修复方法具有重要意义。

发明内容

本发明所要解决的问题是对智能家居物联网系统中IFTTT规则进行安全性验证，并提供一种能够对IFTTT规则进行修正的方法，使得修正后的IFTTT规则下系统安全。

为解决上述问题，本发明采用的方案如下：

根据本发明的一种智能家居物联网系统验证与修复的方法，包括以下步骤：

S1：获取各种不同产商的智能家居设备描述信息、设定的智能家居设备之间的IFTTT规则以及系统不安全状态；

S2：根据所述的智能家居设备描述信息和所述的IFTTT规则构建混成自动机模型；

S3：通过SMT约束求解的方法对混成自动机模型进行安全验证，通过判断系统不安全状态是否可达判断系统是否安全；

S4：当步骤S3判断出系统为不安全，对所述IFTTT规则This条件中的实数型条件值进行修正，修正后重复步骤S2、S3、S4直到步骤S3判断出系统为安全；其中，所述步骤S3包括以下子步骤：

S31：遍历混成自动机的所有路径组，对各个路径组进行可达性分析，找出所有的可达路径组；所述可达性分析为判断路径组在图形结构上是否可能抵达所述的系统不安全状态；所述可达路径组为在图形结构中可能抵达所述的系统不安全状态的路径组；

S32：将每个可达路径组编码成对应的SMT约束；

S33：将所述SMT约束放入SMT求解器进行求解；假如存在一组可达路径组所对应的SMT约束可解，则判断系统为不安全；

所述步骤S4中所述对IFTTT规则This条件中的实数型条件值进行修正包括如下子步骤：

S41：将可解的SMT约束中对应的IFTTT规则中This部分实数型条件值参数化，并将整个SMT约束反向编码，得到参数化的并取反的SMT约束；

S42：将参数化的并取反的SMT约束量词消去后放入SMT求解器求解，获得各个参数的可解值；

S43：用各个参数的可解值替换对应的所述IFTTT规则中This部分实数型条件值。

根据本发明的一种智能家居物联网系统验证与修复的装置，包括：

模块M1，用于获取各种不同产商的智能家居设备描述信息、设定的智能家居设备之间的IFTTT规则以及系统不安全状态；

模块M2，用于根据所述的智能家居设备描述信息和所述的IFTTT规则构建混成自动机模型；

模块M3，用于通过SMT约束求解的方法对混成自动机模型进行安全验证，通过判断系统不安全状态是否可达判断系统是否安全；

模块M4，用于当模块M3判断出系统为不安全，对所述IFTTT规则This条件中的实数型条件值进行修正，修正后重复模块M2、M3、M4直到模块M3判断出系统为安全；

其中，所述模块M3包括以下子模块：

模块M31，用于遍历混成自动机的所有路径组，对各个路径组进行可达性分析，找出所有的可达路径组；所述可达性分析为判断路径组在图形结构上是否可能抵达所述的系统不安全状态；所述可达路径组为在图形结构中可能抵达所述的系统不安全状态的路径组；

模块M32，用于将每个可达路径组编码成对应的SMT约束；

模块M33，用于将所述SMT约束放入SMT求解器进行求解；假如存在一组可达路径组所对应的SMT约束可解，则判断系统为不安全；

所述模块M 4中所述对IFTTT规则This条件中的实数型条件值进行修正包括如下子模块：

模块M41，用于将可解的SMT约束中对应的IFTTT规则中This部分实数型条件值参数化，并将整个SMT约束反向编码，得到参数化的并取反的SMT约束；

模块M42，用于将参数化的并取反的SMT约束量词消去后放入SMT求解器求解，获得各个参数的可解值；

模块M43，用于用各个参数的可解值替换对应的所述IFTTT规则中This部分实数型条件值。

本发明的技术效果如下：

(1)本发明提供了一种对智能家居网络的验证方法，通过自动的模型转换建模对实时系统的安全性进行了验证。

(2)本发明所述模型检验方法对用户的具有较大的自由度的规则有良好的适应性。

(3)本发明所述模型检验方法在建模过程中对智能家居网络的实时性特性进行了充分的考虑，将其特点在模型中显示出来。

(4)本发明所述模型检验方法中不需要使用者具有针对性的专业知识，普通用户也可按照固定规则使用。

(5)本发明不仅可以验证系统安全性，还可以在不安全情况下予以自动修复。

附图说明

图1是本发明方法的流程图。

具体实施方式

下面结合说明书附图对本发明做进一步详细说明。

如图1所示，一种智能家居物联网系统验证与修复的方法，主要包括以下四个步骤：

S1：获取数据的步骤；

S2：构建混成自动机模型的步骤；

S3：模型安全性验证的步骤；

S4：IFTTT规则变量修正的步骤。

步骤S1中，获取数据的步骤中的“数据”由三部分组成，第一部分是设备描述信息，第二部分是IFTTT规则，第三部分是系统不安全状态。设备描述信息是由各种不同产商的智能家居设备自身所定义的，可以由智能家居设备自动提供获得，也可以通过手工编辑获得。需要指出的是，这里的设备描述信息表示的是多个智能家居设备的设备描述信息。每个智能家居设备的设备描述信息包含了设备基本信息定义、设备可访问的数据定义、设备工作状态定义、设备变迁定义以及设备可操作的API接口定义。设备基本信息包括但不限于，名称，类型，序列号，位置等。下述Json格式的文本是两个设备的设备描述信息的实施例。该文本定义两种设备：空气净化器Air_Purifier和警报器ALARM。

上述Json格式文本中，“SN”表示序号，两个设备的序号分别定义为0001和0002。“Type”为设备类型。“InternalVari”表示设备可访问的数据，其中，空气净化器定义了参数名称为“CO_level”，数据类型为“int”的设备可访问的数据，该参数表示空气净化器检测到的一氧化碳的水平。“WorkingMode”为设备工作状态定义，其中，空气净化器定义了“Closed”和“Working”两种状态；警报器定义了“ON”和“OFF”两种状态。“Transitions”为设备变迁。“API”为设备可操作的API接口定义，其中，空气净化器定义了“ACTIVATE”和“PAUSE”两个API接口；警报器定义了“TURN_ON”和“TURN_OFF”两个API接口。

IFTTT规则由用户编辑输入。下述IFTTT规则基于上述空气净化器和警报器两种设备：

IF Air_Purifier.CO_level>195 THEN Execute ALARM.TURN_ON command

IF ALARM.ON THEN Execute Air_Purifier.ACTIVATE command

IF Air_Purifier.CO_level<120 THEN Execute ALARM.TURN_OFF command

IF Air_Purifier.CO_level<40 THEN Execute Air_Purifier.PAUSE command

上述IFTTT规则中，用户定义了两个触发规则：规则一，当空气净化器检测到一氧化碳水平超过195时，则打开警报器；规则二，当警报器的状态为开的时候，则激活空气净化器对空气进行净化；规则三，当一氧化碳水平低于120时，关闭警报器；规则四，当一氧化碳水平低于40时，停止空气净化器对空气的净化。

系统不安全状态是用于给定的。比如用户不希望系统中出现某种状态，在该状态下，设备A在某个模式下并且其上的变量满足某约束，同时设备B处于某个模式。用户不希望系统中出现这种状态，原因可能是这种状态下用户认为系统不安全，也可能是其他原因。而对于本发明来说，既然用户不希望这种状态的出现，那么，这就是一种系统不安全状态。

需要说明的是，这里的“获取”表示的是智能家居设备描述信息和IFTTT规则是为本发明的输入。至于如何“获取”智能家居设备描述信息和IFTTT规则并不是本发明所讨论的范畴。本说明书后续实施以上述空气净化器和警报器和IFTTT规则为例。

步骤S2的输入是步骤S1所获取的设备描述信息和IFTTT规则。步骤S2也就是根据输入的智能家居设备描述信息和IFTTT规则构建混成自动机模型。这里的混成自动机是由设备描述信息中所定义的设备自身的状态变迁和IFTTT规则所定义的状态变迁组成。以前述空气净化器、警报器和IFTTT规则为例。空气净化器有两种工作状态“Closed”和“Working”。当执行“ACTIVATE”命令，空气净化器由“Closed”状态转成“Working”状态；当执行“PAUSE”命令，空气净化器由“Working”状态转成“Closed”状态。警报器有两种工作状态“ON”和“OFF”。当执行“TURN_ON”命令，警报器由“OFF”状态转成“ON”状态；当执行“TURN_OFF”命令，警报器由“ON”状态转成“OFF”状态。空气净化器和警报器的这种状态变迁是设备自身的状态变迁。而由IFTTT规则带来的，当空气净化器检测到一氧化碳水平超过195时，则打开警报器；当警报器的状态为开的时候，则激活空气净化器对空气进行净化的状态变迁是IFTTT规则所定义的状态变迁。这是由设备自身的状态变迁和IFTTT规则状态变迁混合而成的自动机，因此称为混成自动机。这种状态变迁通常用图表示，该图的每个节点表述状态，节点之间的连线表示触发动作，从一个节点到另一个节点的连线构成一个路径。具体到数据结构上，混成自动机模型可以用两组数组表示：DevicePath_Set和IFTTTPath_Set。DevicePath_Set是设备自身的状态变迁可以表示成{DevicePath_i|i∈[1..N]}；IFTTTPath_Set是IFTTT规则状态变迁可以表示成{IFTTTPath_i|i∈[1..M]}。其中，DevicePath_i表示为单次的设备状态变迁的路径，由开始状态StartState，结束状态EndState，以及触发动作Action组成。其中，IFTTTPath_i表示为单个IFTTT规则的状态变迁的路径，由开始状态StartState，结束状态EndState，以及触发条件Condition组成。

步骤S3是模型安全性验证的步骤，也即通过SMT约束求解的方法对步骤S2中的混成自动机模型进行安全验证，判断系统是否安全。具体处理过程如下：

首先步骤S31，遍历混成自动机的所有路径组，对各个路径组进行可达性分析，找出所有的可达路径组。这里，对路径组可达性分析为判断路径组在图形结构上是否可能抵达系统不安全状态，而可达路径组为在图形结构中可能抵达系统不安全状态的路径组。这里的系统不安全状态是由步骤S1输入的。这里“可能抵达”是指通过路径分析，可以到达系统不安全状态的路径组。而实际上，通过状态变迁分析，有可能根据该路径组到达系统不安全状态，也可能无法到达系统不安全状态。也因此才有后续的步骤S32和S33步骤对可达路径组进行进一步分析。假如本步骤找不到可达路径组，那么，也就认为，系统不会出现该系统不安全状态，此时系统认为是安全的，可以结束分析。

然后是步骤S32，将每个可达路径组编码成对应的SMT约束。步骤S2获得的混成自动机是一种有界模型，对于有界模型的验证编码可参照文献：Xie Dingbao,Bu Lei,ZhaoJianhua,Li Xuandong.SAT-LP-IIS joint-directed path-oriented boundedreachability analysis of linear hybrid automata.In Formal Methods in SystemDesign,45(1):42-62,2014。

以下述路径为例：

Air_Purifier_0001:Closed∧Signal_Above_195∧Closed∧ACTIVATE∧Signal_ACT IVATE∧Signal_ACTIVATE∧Working

ALARM_0002:OFF∧TURN_ON∧Signal_TURN_ON∧Signal_TURN_ON∧ON

可将其编码成如下SMT约束：

最后是步骤S33，将步骤S32得到各个的SMT约束放入SMT求解器进行逐个求解。一个可达路径组对应一个SMT约束。假如某个SMT约束可解，意味着前述的系统不安全状态可达，系统不安全。假如所有的SMT约束都不可解，则意味着前述的系统不安全状态不可达，系统安全，结束处理。

步骤S4是IFTTT规则变量修正的步骤，也可以称为IFTTT规则条件值修正的步骤。也就是，当步骤S3判断出系统为不安全，对IFTTT规则This条件中的实数型条件值进行修正。系统不安全也就是前述步骤S33中，存在某个SMT约束在SMT求解器中可解。假如存在某个SMT约束可解，则根据该可解的SMT约束对IFTTT规则This条件中的实数型条件值进行修正。以前述IFTTT规则为例，即对IFTTT规则中This条件中“Air_Purifier.CO_level>195”“Air_Purifier.CO_level<120”“Air_Purifier.CO_level<40”中的存在实数型条件值“195、120、40”进行修正。也即修改“195、120、40”具体值使得其对应的SMT约束不可解。假如修改后，其对应的SMT约束不可解，那么距离系统安全进了一步。假如修改后，其对应的所有SMT约束不可解，那么条件者修正后，系统安全。修改的方法如下：

首先，步骤S41，将可解的SMT约束中对应的IFTTT规则中This部分实数型条件值参数化，并将整个SMT约束反向编码，得到参数化的并取反的SMT约束。该步骤分为两个动作：一个是将SMT约束中对应的IFTTT规则中This部分实数型条件值参数化；一个是SMT约束反向编码。以前述IFTTT规则为例，也即IFTTT规则中This条件中实数型参数“195、120、40”中用变量K1、K2、K3表示。于是，SMT约束中的相应的“Air_Purifier.CO_level>195”“Air_Purifier.CO_level<120”、“Air_Purifier.CO_level<40”成为：“Air_Purifier.CO_level>K1”“Air_Purifier.CO_level<K2”、“Air_Purifier.CO_level<K3”。反向编码，也即，将前述SMT约束中的条件“Air_Purifier.CO_level>K1”、“Air_Purifier.CO_level<K2”、“Air_Purifier.CO_level<K3”替换成“Air_Purifier.CO_level<＝K1”、“Air_Purifier.CO_level>＝K2”、“Air_Purifier.CO_level>＝K3”。SMT约束参数化的步骤和取反的步骤不分先后，可以首先参数化，然后执行反向编码；也可以首先反向编码，然后参数化。这两种不同顺序最终得到的结果是相同的。需要指出的是，这里的反向编码是对SMT约束中所有的约束条件进行反向编码。

然后，步骤S42：将参数化的并取反的SMT约束量词消去后放入SMT求解器求解获得各个参数的可解值。这里“量词消去”是证明数学理论问题可判性的一种方法，本实施例中，量词消去采用了redlog工具。有关量词消去方法和relog工具属于本领域技术人员所熟悉的技术，可参照http://redlog.dolzmann.de/，本说明书不再赘述。本步骤的意思是：原始的SMT约束是可解的，SMT约束取反后必然不可解。将参数变量K1、K2、K3代入SMT约束后，就是要找出一组K1、K2、K3的值，使得SMT约束取反后可解。SMT约束取反后可解意味着SMT约束自身不可解。也就是找出一组K1、K2、K3的值使得SMT约束不可解。具体的手段就是将参数化的并取反的SMT约束量词消去后放入SMT求解器求解，假如可解，并能得到K1、K2、K3的可解值a1、a2、a3。

IFTTT规则条件值修正的最后一个步骤是步骤S43，也即用各个参数的可解值替换对应的所述IFTTT规则中This部分实数型条件值。这也就是，假如在步骤S42中得到K1、K2、K3的可解值a1、a2、a3。而K1、K2、K3对应了IFTTT规则This部分实数型条件值，如前述的“195、120、40”，那么将“195、120、40”用相应的可解值“a1、a2、a3”替换，于是，原来IFTTT规则This部分的条件“Air_Purifier.CO_level>195”“Air_Purifier.CO_level<120”、“Air_Purifier.CO_level<40”就成为：“Air_Purifier.CO_level>a1”“Air_Purifier.CO_level<a2”、“Air_Purifier.CO_level<a3”。

需要指出的是，假如，步骤S42中，将参数化的并取反的SMT约束量词消去后放入SMT求解器求解是不可解的，这意味着找不到对应的K1、K2、K3的可解值，系统无法修正，则结束处理。

经过上述步骤S41、S42、S43对IFTTT规则This条件中的实数型条件值进行修正后，将修改后的IFTTT规则作为步骤S2、S3、S4的输入按顺序重复步骤S2、S3、S4直到步骤S3判断出系统为安全。

Claims (2)

1.一种智能家居物联网系统验证与修复的方法，其特征在于，包括以下步骤：

S1：获取各种不同生产商的智能家居设备描述信息、设定的智能家居设备之间的IFTTT规则以及系统不安全状态；

S2：根据所述的智能家居设备描述信息和所述的IFTTT规则构建混成自动机模型；

S3：通过SMT约束求解的方法对混成自动机模型进行安全验证，通过判断系统不安全状态是否可达判断系统是否安全；

S4：当步骤S3 判断出系统为不安全，对所述IFTTT规则This条件中的实数型条件值进行修正，修正后重复步骤S2、S3、S4直到步骤S3判断出系统为安全；其中，所述步骤S3包括以下子步骤：

S31：遍历混成自动机的所有路径组，对各个路径组进行可达性分析，找出所有的可达路径组；所述可达性分析为判断路径组在图形结构上是否可能抵达所述的系统不安全状态；所述可达路径组为在图形结构中可能抵达所述的系统不安全状态的路径组；

S32：将每个可达路径组编码成对应的SMT约束；

S33：将所述SMT约束放入SMT求解器进行求解；假如存在一组可达路径组所对应的SMT约束可解，则判断系统为不安全；

所述步骤S4中所述对IFTTT规则This条件中的实数型条件值进行修正包括如下子步骤：

S41：将可解的SMT约束中对应的IFTTT规则中This部分实数型条件值参数化，并将整个SMT约束反向编码，得到参数化的并取反的SMT约束；

S42：将参数化的并取反的SMT约束量词消去后放入SMT求解器求解，获得各个参数的可解值；

S43：用各个参数的可解值替换对应的所述IFTTT规则中This部分实数型条件值。

2.一种智能家居物联网系统验证与修复的装置，其特征在于，包括：

模块M1，用于获取各种不同生产商的智能家居设备描述信息、设定的智能家居设备之间的IFTTT规则以及系统不安全状态；

模块M2，用于根据所述的智能家居设备描述信息和所述的IFTTT 规则构建混成自动机模型；

模块M3，用于通过SMT约束求解的方法对混成自动机模型进行安全验证，通过判断系统不安全状态是否可达判断系统是否安全；

模块M4，用于当模块M3判断出系统为不安全，对所述IFTTT规则This条件中的实数型条件值进行修正，修正后重复模块M2、M3、M4直到模块M3判断出系统为安全；

其中，所述模块M3 包括以下子模块：

模块M31，用于遍历混成自动机的所有路径组，对各个路径组进行可达性分析，找出所有的可达路径组；所述可达性分析为判断路径组在图形结构上是否可能抵达所述的系统不安全状态；所述可达路径组为在图形结构中可能抵达所述的系统不安全状态的路径组；

模块M32，用于将每个可达路径组编码成对应的SMT约束；

模块M33，用于将所述SMT约束放入SMT求解器进行求解；假如存在一组可达路径组所对应的SMT约束可解，则判断系统为不安全；

所述模块M 4中所述对IFTTT规则This条件中的实数型条件值进行修正包括如下子模块：

模块M41，用于将可解的SMT约束中对应的IFTTT规则中This部分实数型条件值参数化，并将整个SMT约束反向编码，得到参数化的并取反的SMT约束；

模块M42，用于将参数化的并取反的SMT约束量词消去后放入SMT求解器求解，获得各个参数的可解值；

模块M43，用于用各个参数的可解值替换对应的所述IFTTT规则中This部分实数型条件值。