基于环境建模的物联网系统TAP 规则生成方法*

边 寒 ,陈小红 ,金 芝 ,张 民

1(上海市高可信计算重点实验室(华东师范大学),上海 200062)

2(北京大学 信息科学技术学院 计算机科学与技术系,北京 100871)

3(高可信软件技术教育部重点实验室(北京大学),北京 100871)

物联网(IoT)系统通过网络连接的传感器和执行器监视、调度、管理各种设备,如汽车、交通信号灯、空调、灯等,为用户提供各种智能服务以满足用户服务需求,为用户的日常生活提供便利.在这样的系统中,用户服务需求是智能服务的根本驱动力.近年来提出的物联网面向用户编程框架,如IFTTT 和Microsoft Flow[1],就是这种背景下的产物.它们允许用户使用简单的“IF trigger,THEN action(称为触发-命令编程,TAP)”规则编程.在图1 所示的智能家居系统中,用户可以编出这样的规则:“如果光线亮度超过 50 000lux,则关上窗帘”,这个规则用TAP 描述为“IF Light.brightness>50000lux THEN close the blind”.但是,实际上这种TAP 句法描述的是设备调度程序,通知软件去关窗帘,既不是用户服务需求也不是系统行为,服务需求贴近用户的需要,比如用户想要窗帘关闭使得光线暗点,系统行为贴近软件,它关心软件是否要发出关窗帘的脉冲的事件,但TAP 句法中的“action”是指通知软件去关窗帘的指令,既不同于状态“窗帘关闭”,也不同于事件“关窗帘的脉冲”.

一些物联网系统提出采用面向目标的需求方法,如文献[2]使用领域模型和UML 图来捕获服务需求,支持服务目标的分解,但没有提出措施来保障物联网不同服务间的一致性和服务部署的完整性,容易出现一致性和完整性问题.一致性问题是指有两条或两条以上的服务需求之间出现冲突[3,4],而完整性问题是指在某些情况下的输入,软件无法给出确切的输出[5].对于软件系统来说,任何由于不一致、不完整导致的差错,都可能在现实世界中产生不良后果,甚至对用户的财产、生命造成威胁[6].在物联网系统中,使用TAP 进行用户编程时,用户并不会去考虑一致性、完整性问题,使得这些问题更加突出.例如,在一个智能家居软件系统中,如果用户规定当一氧化碳的浓度高于一定阈值时自动开窗,又规定下雨时自动关窗,那么如果下雨时一氧化碳浓度过高,同时满足这两条需求,便会出现一致性问题,在这种情况下,房间的一氧化碳浓度可能会超过200mg/L,这是有害甚至致命的;再比如规定亮度低于一定阈值时开灯,但没有规定高于这个阈值时的行为,那就会出现完整性问题,导致灯一直开着,严重浪费能源.现在已有很多工作提供对TAP 规则的一致性的检测与修复[7,8],但并没有在服务需求层面和系统行为层面上的检测.

为了实现正确的“用户编程”,本文提出在用户提供的服务需求的基础上,从服务需求中自动推导系统行为,并检测一致性和完整性,最后自动转换为TAP 形式的设备调度程序.在定义服务需求时,基于环境建模的需求工程思想[9,10],本文认为将服务需求指称到设备的状态变化上更合适,比如用户希望的是灯灭了,而不关心用的是哪种行为使得灯关了.在从服务需求到系统行为的推导过程中,根据文献[11],必须考虑到环境特性,在检测一致性、完整性时,也需从设备的角度去考虑,因此,本文提出基于环境建模的物联网系统TAP 规则生成方法,实现了服务需求到程序的自动化,主要贡献包括:

(1) 建立了物联网应用场景的环境本体,提供了环境建模的基本概念和关联.针对物联网应用场景环境的特点,定义了被监视实体和被控制实体,并用属性和状态机对相应特征进行了建模;

(2) 给出了基于环境的用户服务需求的定义,将服务需求指称到状态变化上,定义了基于环境本体的用户服务需求描述方法;

Fig.1 An example of smart house图1 智能家居的例子

(3) 定义了物联网系统的需求一致性和完整性规则,基于环境本体使用问题图[12]进行服务需求到系统行为的自动转换,以及基于规则完成了需求的一致性与完整性的检测.

本文第1 节介绍系统行为推导中要使用的问题图.第2 节定义物联网系统的环境本体.第3 节给出本文的方法.第4 节给出关键算法.第5 节设计实验,对本文方法进行评估.第6 节比较相关工作.第7 节总结全文,展望未来工作.

1 预备知识

问题图是问题框架方法[12]需求描述的结果,在本文中用来承载用户服务需求和软件行为.图2 给出了问题图的简单示例,软件问题就是要指定一个待开发系统(控制机器controller machine)来监视、控制问题领域(空气air 和空调air conditioner),以满足需求(调节温度adjust temperature).问题领域与机器之间的连接称为接口(一种交互),指明了它们之间共享的现象,如控制机器与空调之间共享现象开脉冲(OnPulse)和关脉冲(OffPulse).接口由一方发起,用“发起者!{内容}”表示,内容可以是现象中的事件、状态或取值.需求表示为一段自然语言描述的期望,实际指称为人们期望在问题领域上发生的改变,如期望室温T>30,或者空调打开(on)或关闭(off)等,这种期望现象称为需求现象.对那些只能观察而无法控制的需求现象的引用称为需求引用:如对于室温,只能观察、引用,而不能控制;而对那些可以控制的需求现象的约束称为需求约束:如对于空调,人们可以控制它的开关.需求引用和需求约束都可以表示为接口交互的形式.

Fig.2 Simple example of a problem digram图2 问题图的简单示例

问题图的左右两边分别承载了用户服务需求和软件行为.其中,用户服务需求用需求现象及其之间的关系来描述,表示在问题图右边的需求引用和约束处.如图2 中右边虚线处a和c中的需求现象,要求当温度高于30°、低于20°时,空调要处于打开和关闭状态,这是用户需要的,是用户的服务需求.软件行为用规约现象及其现象之间的关系来描述,表示在问题图左边的接口处.如图2 左边实线接口a和b处,共享现象要求当温度高于30°时,控制器发出开空调的脉冲,而温度低于20°时则发出关空调的脉冲,这规定了软件的系统行为.需要注意的是,在问题图中,从用户服务需求中导出软件系统行为需要领域知识,本文使用环境本体来描述这些领域知识.

2 物联网系统的环境本体

本体是共享概念模型的明确的形式化规范说明[13].我们定义环境本体来提供环境建模的基本概念和概念间的关联.根据是否领域相关,将环境本体分为两类:上层环境本体和领域环境本体.其中,上层环境本体描述通用的环境建模中的概念和关联,领域环境本体则是针对某个具体的领域的环境建模的结果,是对上层环境本体概念和关联在特定领域中的实例化.

2.1 上层环境本体

物联网系统的环境可以看作是与系统发生交互的一组实体(称为环境实体)的集合,因此环境实体(environment entity)是环境本体中的最基本的概念.在具体的应用场景中,智能家居中的灯、窗帘、人、空气等都是环境实体.这些环境实体可以分为两类.

(1) 被监视的环境实体(monitored entity):这类环境实体仅可被物联网系统以监视的方式获取其状态值,但却无法直接改变这些实体的状态,即,实体的状态是自主变化,不以人的意志为转移的.例如,智能家居中涉及到的室内空气、光照等;

(2) 被控制的环境实体(controlled entity):对于这类环境实体,不仅可以获取其状态值(即各项属性值),而且可以向这些环境实体发送事先定义好的指令,以改变其状态.各种嵌入式设备均属于该类实体,如智能家居中的日光灯、窗户、电动窗帘等.而它们的改变既可以是状态也可以是属性值,例如,灯既可以用“开、关”来描述,也可以用具体的亮度数值来描述.

对于每个环境实体,都可以用属性(attribute)来描述其特性,每个属性都有取值(value).比如被监视的环境实体光线(light),它有属性亮度,可以用Light.brightness表示,其取值代表光线亮度的大小;再如被控制的环境实体Bulb,它的属性为BulbST,即灯的状态,其属性值可以为bon或boff,表示灯的开关状态.除了属性之外,还可以使用状态机(state machine)来描述一些被控制实体的动态特性,状态机有状态(state)、状态变迁(transition),而状态变迁由事件(event)触发.比如可以用带有状态bon、boff的状态机描述灯的动态特性,当灯接收到开灯的脉冲(bonPulse)时状态转为bon,而当灯接受到关灯的脉冲(boffPulse)时状态转为boff.

这些概念之间还存在着一定的关联.图3 给出了这些概念之间的关联,这些关联的含义见表1.

Fig.3 Concept association diagram of environment ontology图3 环境本体的概念关联图

Table 1 Relations and meanings of concepts in environment ontology表1 环境本体概念关联及其含义

2.2 智能家居的领域环境本体

以智能家居为例,我们来说明领域环境本体的构造.首先识别领域中的环境实体.假设智能家居领域中包含的被控制环境实体有窗户(window)、窗帘(blind)和灯(bulb),而被监视环境实体有光照和空气.这些都是环境实体的实例.窗户的属性为WindowST,描述窗户的开闭,其取值为wopen或wclosed;窗帘的属性为BlindST,描述窗帘的开闭,其取值是bopen或bclosed;灯的属性为BulbST,描述灯的开关,其取值是bon或boff;光照的属性为brightness,表示亮度,其值在理论上可以是大于0 的任意值;空气的属性为温度(temperature)和湿度(humidity),temperature表示气温,其值在理论上可以为–273.15 摄氏度到正无穷;humidity表示空气的相对湿度,其值在理论上可以为0 到正无穷.这些具体的属性和取值分别是属性和值这两个概念的实例.

对于每个被控制实体,需要进一步识别其状态机.在智能家居领域中,窗户、窗帘和灯的状态机如图4 所示,以灯为例,当其处于bon状态时,表示灯开着,如果此时收到一个bonPulse事件,则继续开着,如果收到boffPulse事件,则关闭;当其处于boff状态时,表示灯关着,如果此时收到一个bonPulse事件,则灯打开,反之,如果收到boffPulse事件,则仍然关闭.这些都是状态机、事件、状态、迁移概念的具体实例.

Fig.4 State machine of controlled environment ontology in smart home systems图4 智能家居系统的被控制环境实体的状态机图

3 本文方法

在环境本体的支持下,本文提出了生成TAP 规则的方法框架,如图5 所示.在用户撰写服务需求后,首先借助环境本体对系统行为进行推导,得到初始问题图,然后对其进行一致性、完整性检测.若通过检测,则将检测后的问题图结合现象指令对照表生成TAP 规则,否则返回给用户修改服务需求.

Fig.5 Architecture of our approach图5 本文方法框架

3.1 用户服务需求的撰写

首先,我们来定义用户的服务需求.本文基于环境建模思想,将服务需求指称到环境实体变化上,在物联网系统中,环境实体的变化通常表现为环境实体的不同状态.例如,在下雨时,窗户要处于关闭这一状态.沿用但区别于TAP 规则的“IF trigger THEN action”句法,本文将使用如下句法以供用户表达服务需求.

其中,

· entity.trigger 有如下表达方式.

✦ 当entity 为被监视的环境实体时,使用entity.attribute 表示实体的属性取某个值或属于某一范围,例如,光照为3 000lux,则写作Light.brightness=3000,而光照大于3 000lux,则写作Light.brightness>3000(为了自动化流程考虑,仅使用数值,省略单位);

✦ 当entity 为被控制的环境实体时,可以使用entity.state 表示实体处于某个状态,如Window.wclosed表示窗户处于关闭状态,也可以是entity.attribute,其表达方式与上一条类似;

✦ 另外,trigger 可以是带有与、或操作符的复杂句子,其中,与关系用&&表示,或关系用符号||表示.

· entity.state 为被控制的环境实体及其状态.

例如,如果用户想表达当光线的亮度大于50 000lux 时窗帘处于关闭状态,则触发条件中的实体为光线,是被监视实体,亮度大于50 000lux 即光线的属性“亮度”大于50 000lux,因此,这个服务需求的entity.trigger 就是Light.brightness>50000;为了表达窗帘处于关闭状态,entity.state 就是Blind.bclosed,因此,这条服务需求为“IFLight.brightness>50000THENBlind.bclosed”.而如果用户想表达当窗帘关闭时灯打开的服务需求,实体为窗帘,是被控制实体,而trigger,即窗帘关闭的状态,就是bclosed,因此,这个服务需求的entity.trigger 就是Blind.bclosed;为了表达开灯,entity.state 就是Bulb.bon,因此,这条服务需求为“IFBlind.bclosedTHENBulb.bon”.

对于复杂的服务需求,即含有与或关系的需求,也采用同样的处理方式.例如,想要表达当气温高于25°且亮度大于25 000lux 时窗户处于打开状态,这个服务需求有两个触发条件,涉及两个被监视实体:空气和光线,触发条件则分别是空气的属性温度大于25°和光线的属性亮度大于25 000lux,因此,这条需求的前半部分是Air.temperature>25 和Light.brightness>25000 的与;而entity.state 就是窗户要处于打开状态,即Window.wopen,因此,这条需求为“IFAir.temperature>25 &&Light.brightness>25000 THENWindow.wopen”.

另外,在用户书写服务需求时就需要引入环境本体,让用户选择相应的设备,而不是随便写.这么做的好处在于:大多数用户并不熟悉所有设备的性能和效果,如果让用户毫无限制地书写需求,将会造成大量因不熟悉设备而造成的错误或遗漏.而环境本体中包含了各个设备及其状态、效果,使用环境本体能够在用户书写服务需求时提示他们设备的效果,防止用户写出一些荒谬的服务需求,从而减少后期检测与修改的工作量.

3.2 系统行为的推导

系统行为的推导分为两步.

第1 步,将第3.1 节定义的服务需求标记到问题图中.每一条服务需求都能对应一个问题图,其中的信息可以定义问题图的右边部分.具体的对应如下所示:首先是环境实体与问题领域的对应,在“IF 〈entity.trigger〉THEN 〈entity.state〉”中,entity 就是与系统交互的环境实体,它们就是问题图的问题领域,就像图6 中的服务需求“IFAir.temperature>30 THENWindow.wopen”的Air和Window可以直接转换成问题领域Air和Window.其次,trigger 和state 与需求引用和约束中的现象相对应,trigger 作为需求的条件,表示对需求的引用,可以直接画为需求引用,而state 则是用户期望看到的现象,是对需求的约束,可以直接画为需求约束,现象发起者应该是其前面的entity.如图6 中Air.temperature>30 就可以直接转为需求引用Air!{temperature>30},Window.wopen可以直接转为需求约束Window!{wopen}.椭圆形需求里面直接标注标号即可,如图6 中的Req1.

第2 步则需要根据环境本体推导相应的系统行为,即定义问题图的左边接口部分.对于简单服务需求,即entity.trigger 中没有与或关系的,考虑trigger 和state 的不同实体类型,分别加以处理.

· 无论entity.trigger 中的entity 是被监视实体还是被控制实体,都将需求引用中的条件直接拷贝过来,就像图6 中的M和Air之间的接口.

· 对于entity.state 中的实体,则需要通过其状态机,查找触发状态state 的事件,将其作为共享现象放在接口中,而且这个接口必须是软件发出的,如图6 所示,Window状态机里的状态wopen的触发事件为wopenPulse,则接口就可以定义为M!{wopenPulse}.

而针对包含与或关系的复杂用户服务需求,其处理可如下所示.

· 如果是与关系连接了多个entity.trigger,则对于每一个entity.trigger,该entity 对应的问题领域都要与需求通过需求引用相连,然后在需求引用上根据trigger 添加需求现象;

· 如果是或关系连接,即“IFa||bTHENentity.state”形式的需求,则表示若a发生或者b发生,entity 都应该处于state 状态,那么若将a和b拆开,使得这条需求变为两条,即“IFaTHENentity.state”和“IFbTHENentity.state”,其代表的含义也是一样的.比如“IFAir.temperature<25||Air.humidity>25 THENWindow.wclosed”,就可以拆为“IFAir.temperature<25 THENWindow.wclosed”和“IFAir.humidity>25 THENWindow.wclosed”.因此,对这种带有或关系的需求,我们将其拆解为两句,分别转换为问题图.

Fig.6 Schematic diagram of problem diagram generation图6 问题图生成的示意图

3.3 一致性与完整性的检测

我们从环境实体的角度来定义不一致与不完整,在常规的服务需求不一致的定义的基础上,根据trigger 和state 的不同情况,本文考虑3 种类型的需求不一致.

(1) 范围不一致:超过一条需求的trigger 中的范围有交集,而它们的state 实体相同,内容不同,导致需求发生冲突.例如,智能家居系统的用户规定“IFLight.brightness<30000 THENWindow.wclosed”和“IFLight.brightness>15000 THENWindow.wopen”,那么,当亮度处于15 000lux 到30 000lux 之间时,这两条需求同时作用在窗户上,但state 正好相反,从而导致了范围不一致的情况;

(2) 与或不一致:一条需求中trigger 复杂的与、或关系所导致上午不一致.例如,如果用户规定“IF (Air.temperature>25 &&Light.brightness>25000)&&(Air.temperature<25 &&Air.humidity<30)THENWindow.wopen”,该需求前半句要求温度高于25°而后半句要求温度低于25°,使用与连接说明需要同时满足这两个条件,因此这是永远也无法达到的,从而导致了与或的不一致.

(3) 覆盖不一致:多条需求state 中的实体相同、内容不同,于是不同的trigger 导致后执行的state 覆盖了先执行的state.例如,一条需求要求亮度大于20 000lux 时灯处于关闭状态,而另一条需求要求窗帘关闭时灯处于打开状态,假如亮度大于20 000lux 时,窗帘关上了,那么此时根据需求2,灯应该是打开的,于是开灯的状态覆盖了关灯的状态,但其实此时亮度仍然大于20 000lux,根据需求1,灯应该是关闭的,从而导致覆盖不一致的情况.

从服务需求的定义出发,根据环境实体的性质,本文考虑如下两种需求不完整的情况.

(1) 状态不完整:将所有服务需求对应的问题图合并起来,它们并没有涉及到环境本体中所有实体的所有状态,从而导致需求的不完整.例如,在一组需求中,只有窗帘状态为开的情况,却并没有使得窗帘状态为关的情况(即Blind.bclosed),而这是不完整的;

(2) 属性不完整:所有需求的trigger 并没有覆盖到对应实体属性可达的全部范围,导致在某些情况下无法准确地判断实体该处于的状态.例如,两条需求分别规定了Light.brightness>20000 与Light.brightness<15000 时灯应该处于打开和关闭的状态,但当亮度处于15 000lux 和20 000lux 中间情况时,是否应该保持上一时刻的状态?还是根据一些其他标准来决定是否改变灯的状态?这在灯的服务需求中并没有提到,因此这是不完整的.

3.4 TAP规则的生成

TAP 规则的生成分为两个阶段.

(1) 从问题图生成系统行为:根据检测过的问题图,首先确定问题图中的问题领域中是对应需求引用还是需求约束,若为引用,则其问题领域的接口对应IF 里面的内容,如果有多个引用,则使用“&&”进行连接;若为约束,则其问题领域的接口对应 THEN 里面的内容.如图 7 所示,问题领域Air是需求引用,则其接口“Air!{temperature>30}”为IF 里的内容,而问题领域Window对应的是需求约束,则其接口“M!{wopenPulse}”为THEN里的内容,由此生成系统行为:IFAir.temperature>30 THENM.wopenPulse,但这并不是最终的TAP 规则.

(2) 从系统行为到TAP 规则:将系统行为与现象指令对照表中的相关条目进行对照后才能生成最终的TAP规则.其中,现象指令对照表是一组软件行为与指令的对应关系,如图7 所示,wopenPulse对应指令open the window,这个对照表可以由设备领域专家提供.将系统行为中的“M.wopenPulse”替换为指令open the window,就可以得到TAP 规则“IFAir.temperature>30 THENopen the window”.

Fig.7 Schematic diagram of generating TAP rules图7 TAP 规则生成示意图

4 关键算法

为了实现第3 节中提出的方法,我们开发了TAP 规则生成工具,可以通过http://re4cps.org/dsigs 对其进行访问,相应的视频demo 在http://re4cps.org/examples#DSIGS 给出.本节给出一些关键算法,主要包括:服务需求转换为问题图的算法、一致性检测算法和完整性检测算法以及TAP 生成算法.

4.1 服务需求转换为问题图的算法

服务需求转换为问题图算法就是要实现第3.2 节中提到的系统行为的推导,该算法的主要思路是:首先处理服务需求中的与、或关系,然后对于每一条服务需求,依照第3.2 节所述的对应关系,根据服务需求构建问题图的问题领域和引用,最后借助环境本体构建问题图的接口.

具体步骤如算法1 所示.其中,第5 行～第7 行对服务需求中的与、或关系进行预处理,第9 行～第13 行循环遍历需求的entity.trigger(如果没有与关系连接多个entity.trigger,则循环只进行1 次),构建与trigger 有关的问题领域、需求引用和接口,第14 行～第16 行则处理entity.state,构建与其有关的问题领域、需求约束和接口.假设服务需求的总条数为n,算法中有两个循环,均与n有关,因此该算法的时间复杂度为O(n2).

算法1.服务需求转换为问题图.

输入:所有服务需求reqs,环境本体eo;

输出:问题图集合ProDgms={prodgm1,prodgm2,...,prodgmn}.

4.2 一致性检测算法与完整性检测算法

根据第3.3 节给出的一致性和完整性定义,我们设计需求的一致性检测算法和完整性检测算法.一致性检测算法的主要思路是:首先根据问题图的需求引用和需求约束,获取所有的(trigger,state)对;然后检测实体相同的state 对应的trigger 是否有重合,从而检测范围不一致和覆盖不一致,将不一致的需求反馈给用户;最后根据(trigger,state)对中的trigger 检测是否发生与或不一致,如果发生,则将对应的需求反馈给用户.

一致性检测算法的具体步骤如算法2 所示,算法第2 行抽取所有问题图中的(trigger,state)对,第3 行构造entityMap 存放实体相同、内容不同的state 对应的trigger,根据entityMap,第4 行～第17 行的循环检测范围不一致与覆盖不一致,第18 行～第29 行的循环则根据所有trigger 检测与或不一致,检测过程中如果出现了不一致,则输出不一致的需求,算法返回false,若没有不一致,则算法最终返回true.算法中最深的嵌套循环有3 个,但2 个循环都执行常数次,因此,算法2 的时间复杂度是O(n).

为了获取需求引用包含的所有trigger 及对应的state,本文设计了resolveProDgm函数来抽取所有问题图中的(trigger,state)对,其具体步骤如算法3 所示,算法第3 行遍历所有问题图中的需求,第7 行～第9 行的循环读取需求引用中的现象,获取trigger,第10 行读取需求约束中的现象,获取state.假设需求的条数为n,算法的时间复杂度为O(n).

完整性检测算法的主要思路是:首先抽取所有问题图中的(trigger,state)对;然后将涉及到的所有state 与环境本体对比,检测状态不完整,将没有涉及到的状态反馈回用户;最后根据拥有相同实体的state 对应的trigger,检测属性不完整,将没有覆盖到的情况反馈回用户.其主要步骤如算法4 所示.算法的2 行调用resolveProDgm函数,获取了所有的(trigger,state)对,第4 行～第6 行的循环初始化states,第7 行～第13 行根据states 和环境本体检测状态不完整,第14 行～第24 行的循环则检测属性不完整.假设需求数量为n,算法4 的第2 行用到了resolveProDgm函数,其时间复杂度为O(n),而之后的循环都只有1 层,最多只循环n次,因此该算法的时间复杂度为O(n).

4.3 TAP规则生成算法

根据第3.4 节TAP 规则的生成方法,可以设计具体生成算法,其主要思路为:首先根据问题图需求引用对应接口中的内容,确定TAP 规则的trigger;然后根据问题图需求约束对应的接口,构建系统行为;最后根据现象指令对照表,获取现象对应的指令,将系统行为转换为TAP 规则.

算法的主要步骤如算法5 所示.第2 行遍历所有检测后的问题图,第6 行获取所有需求引用对应的问题领域,第7 行～第10 行的循环获取这些问题领域对应接口中的现象,作为TAP 规则的trigger,第10 行为系统行为,第11 行根据映射table(即现象指令对照表)将系统行为转换为对应的指令.假设需求条数为n,嵌套的2 个循环,即第6 行的循环执行常数次,因此,该算法的时间复杂度为O(n).

算法2.一致性检测算法.

输入:问题图集合ProDgms={prodgm1,prodgm2,..,prodgmn};

输出:是否满足一致性以及不满足一致性的需求.

算法3.resolveProDgm:解析问题图,抽取所有trigger 与state.

输入:问题图集合ProDgms={prodgm1,prodgm2,...,prodgmn};

输出:ProDgms 中的所有(trigger,state)对,将其存放在映射map 中.

5 方法评估

以智能会议室系统为背景,本节对本文方法进行评估,主要回答以下几个问题.

(1) 本方法的准确性和效率如何?与人工编写TAP 规则相比,使用本文方法制定TAP 规则会有更高的准确性和效率吗?

(2) 本方法的性能如何?是否适用大规模系统?

(3) 环境本体的构建时间是否对方法的使用造成影响?

算法4.完整性检测算法.

输入:问题图集合ProDgms={prodgm1,prodgm2,...,prodgmn},环境本体eo;

输出:是否满足完整性,若不满足,则输出为何不满足.

算法5.TAP 生成算法.

输入:检测后的问题图集合ProDgms={prodgm1,prodgm2,...,prodgmn},现象指令对照表table;

输出:TAP 规则集合rules.

5.1 准确性与效率

为了回答这个问题,我们设计了一系列对比实验:首先将用户分为两组:本方法组和TAP 组.本方法组首先书写服务需求,然后通过本文方法,在进行一致性、完整性的检测和修改后,生成TAP 规则;而TAP 组则由人工直接编写TAP 规则,并对其进行一致性、完整性的检测和修改.为了避免用户背景造成的差异,我们又将用户分为两类:专业类和非专业类.其中,专业用户为软件工程在读的学生,他们参加过一些与需求相关的课题,有一定的需求工程方面的知识;非专业用户为旅游经济学、医学或语言学专业的学生,没有任何计算机或软件工程方面的学科知识.由此,本方法组和TAP 组又分别分为两个对照组,共4 组实验.我们总共邀请了24 名用户,每组各6 名.

我们请每个用户对一个限定的物联网场景书写10 条需求,规定该场景中的实体只有空气、光线、人、窗户、窗帘、投影仪、空调和灯,空气有温度和湿度两个属性,光线有亮度属性,人可以按下投影仪的开关,窗户和窗帘有open和closed的状态,投影仪和灯有on和off的状态,而空调的状态则可以是cold、hot和off.对于专业的本方法组,我们告知他们书写需求的格式、环境中的实体以及实体的状态取值;对于非专业的本方法组,由于对领域知识没有了解,我们直接告诉他们需求句式IF entity.trigger THEN entity.state 中,entity.trigger 和entity.state 的可填内容;对于专业的TAP 组,我们告知他们编写规则的格式、环境中的实体以及实体的状态取值,让他们推测环境本体中的指令;对于非专业的TAP 组,我们直接告诉他们规则句式IF entity.trigger THEN action 中entity.trigger 和action 的可填内容.对于两个TAP 组,在编写完规则后,告诉他们一致性、完整性的定义,并要求他们对自己编写的规则进行手动检测和修改.

在每组实验中,我们分别统计本方法组用户书写需求所花费的时间,本方法组用户检测和修改需求使其满足一致性与完整性花费的时间,TAP 组用户编写规则所花费的时间,TAP 组用户人工进行一致性与完整性检测所花费的时间,TAP 组用户修改规则花费的时间,所有用户修改前、后的一致性、完整性错误数以及所有用户最终得到的TAP 规则的准确率.在实际记录时,两个本方法组由于使用计算机程序自动地对一致性、完整性进行检测,因此检测时间很短,在总时间中,我们忽略了这些检测时间.最终实验结果见表2.

从表2 中可以得出如下结论:本方法的准确率和效率确实超过可用阈值.首先,观察修改前、后的不一致和不完整数量可以发现,相比于TAP 组手动检测和修改错误,使用本方法进行检测和修改大大减少了错误的数量,而对比表中各个组的最后一行可以发现,无论是专业组还是非专业组,使用本方法得到的TAP 规则的准确率普遍高于TAP 组;其次,对比表中各个组的前4 行,即与时间相关的数据可以发现,无论是专业组还是非专业组,尽管本方法组书写需求花费的时间普遍超出TAP 组直接编写规则的时间,但在对其进行一致性、完整性的检测与修改后,本方法组花费的总时间基本上都低于TAP 组.由此我们可以回答问题1,与人工编写TAP 规则相比,使用本文方法生成的TAP 规则确实有更高的准确性和效率.

Table 2 Result of user study表2 调研结果

本方法对非专业用户更有用.无论是花费的总时间,还是最终的准确率,在非专业组中,本方法组都要明显好于TAP 组.原因在于,专业组的用户由于拥有比较丰富的背景知识,在进行人工的一致性、完整性检测时也能做到比较高的准确率,所以这一现象在专业组并不十分明显,但这在非专业组则非常明显.由此我们认为,与人工组相比,使用本文的方法,对非专业用户来说确实更友好.

我们还注意到,同一组中不同用户的书写时间与最终准确率也可能有较大的差异,造成这种差异的原因有二.

其一,用户所书写的需求、编写的规则其复杂程度不同,导致准确率有所不同.如一些用户书写的需求或规则的trigger 都不包含与、或连接符,也不包含受控制实体的状态,仅包含受感知实体的属性值,这样的需求或规则就比较简单,能够写出较高的准确率;而另外一些用户则执着于复杂的需求,这就导致错误较多.

其二,其他领域知识的差异导致了书写时间上的差别.例如,同样学习软件工程并对需求工程有一定认识,一名专业用户仅花费了12 分钟便写完了程序,而另一名专业用户却花费了30 分钟才写完需求,经过询问发现,其对光照的单位勒克斯(lux)和相对湿度没有概念,因此花费了较多时间查阅资料才完成了需求撰写.由此可见,尽管专业背景差距不大,但其他一些影响因素,如生活经验、其他领域的知识等,也会导致评估的结果出现波动.

与人们普遍认知不同,专业组一些用户的最终准确率无法达到100%,且专业组的书写时间大都比非专业组更长.我们探究了其中的原因,准确率无法达到100%是因为他们所写的一些需求尽管没有违反一致性、完整性,但需求本身却是错误的.例如,一名专业用户写的需求“IFAir.humidity>45 THENWindow.open”,当空气湿度大于一定数值(下雨了)时窗户处于打开状态,这是背离生活实际的,因此这是一条没有违反一致性、完整性,但却错误的需求;专业组平均花费更长的时间是因为专业组拥有更多的背景知识,在书写需求时有更多的考量,而非专业组则完全凭借实际经验.

5.2 性 能

本节对本文方法的自动化流程进行性能分析.我们设计了5 组实验,分别评估服务需求转换为问题图的算法、一致性检测算法、完整性检测算法、TAP 生成算法以及整个本文方法的性能.对于每组实验,本文都设计了10 个实验,分别对10 条、30 条、50 条、100 条、200 条、300 条、500 条、800 条、1 000 条、1 200 条需求运行算法,并记录了所花费的时间.本文的实验环境为64 位Win10 系统,Intel(R) Core(TM) i7-9700k CPU @3.60 GHZ,32 G RAM.

每个实验的服务需求都是使用程序自动生成的.当评估服务需求转换为问题图的算法以及TAP 生成算法时,我们生成了完全正确的服务需求;当评估一致性、完整性检测算法以及整个流程时,生成的需求有20%的概率为不一致的需求,20%的概率为不完整的需求,如果生成出不一致的需求,再分别以1/3 的概率随机生成3 种不一致;如果生成出不完整的需求,再分别以1/4、1/4、1/2 的概率随机生成状态不完整、不包含与或的属性不完整、包含与或的属性不完整.为了防止随机性影响评估结果,每个实验进行了10 次,我们分别记录了每次实验的不一致、不完整个数和时间消耗,对10 次结果取平均值作为评估结果.10 组实验的不一致、不完整的平均个数见表3,最终的性能评估结果如图8 所示.

Table 3 Average number of inconsistency/incompleteness and their distribution in experiments表3 实验中的不一致、不完整平均个数及分布情况

由图8 的趋势可以看出,本方法的性能超过可用阈值.服务需求到问题图的转换算法、TAP 生成算法、一致性检测算法与完整性检测算法的用时都在随着需求条数的增加而增加,且速率并没有很大,这与前文算法复杂度为O(n)和O(n2)的计算基本符合.由此可以认定,本方法可适用于大规模系统.

从图8 还可看出,当需求提高到一定数量时,服务需求转换为问题图的算法花费的时间明显超过一致性、完整性检测算法和TAP 生成算法所花费的时间,其原因在于:假设需求条数为n,则由第4 节可知,一致性检测算法、完整性检测算法和TAP 生成算法的时间复杂度都为O(n),但服务需求转换为问题图算法的复杂度为O(n2),因此,转换算法的时间复杂度是高于两种检测算法和TAP 生成算法的,随着需求条数的增加,环境本体中的状态总数相应地增加后,理应花费更多的时间.

另外,图8 中一致性检测算法与完整性检测算法的时间消耗并不是严格的单调递增.我们认为,这与实验设计时每组案例的服务需求中不一致与不完整的数量是有关系的,即服务需求一致(完整)和服务需求不一致(不完整)在检测时所花费的时间是不一样的.为了证明这一点,我们又设计了4 组实验进行对比:第1、第2 组实验分别评估在没有一致性(完整性)错误的情况下运行一致性(完整性)检测算法的性能,而第3、第4 组实验分别评估有一致性(完整性)错误的情况下运行一致性(完整性)检测算法的性能,其中,第3、第4 组实验的一致性、完整性问题的平均个数仍可见表3.每组实验仍然按服务需求的个数分为10 个实验,每个实验做10 次,记录其所花费的时间,结果取平均值.最终结果如图9 所示.

Fig.8 Result of performance analysis图8 性能分析结果

Fig.9 Time cost of consistency and completeness checking图9 一致性与完整性检测的时间消耗

由图9 可以看出,与有错误相比,当问题图中不存在一致性、完整性错误时,进行一致性、完整性检测的时间大为缩短.因此,使用本文方法进行TAP 规则生成时,如果用户书写的需求本身质量极高,没有错误,就不会因为一致性、完整性的检测而增加时间.

5.3 环境本体构建时间

与直接书写TAP 规则相比,使用本方法需要先建立环境本体,本节试图讨论是否值得花费这些时间去建立环境本体:即建立环境本体能否节省更多的其他时间,以及随着需求数的增多,这些建立环境本体的时间消耗能否忽略不计.

在第5.1 节的准确性与效率的评估实验中,环境本体包含5 个被控制实体,它们共有11 个状态、24 个转换关系.尽管用户平均花费了7 分钟来建立和修改环境本体,但与人工检测相比,本方法自动检测一致性、完整性错误,节省了更多时间,加上本文的方法还会提示错误的语句,帮助用户进行修改.可以看出,在10 条需求的情况下,建立环境本体所花费的时间就已经小于本方法节省的时间了,而如果在需求较多的场合,尽管由于实体增多,建立环境本体的时间也有一定的增加,但这与人工检测一致性、完整性花费的大量时间相比,一定是利大于弊的.因此我们认为,使用本方法,花费一些额外的时间建立环境本体可节省更多的时间,是值得的.

本文还设计了一组实验以证明上述结论.我们认为,尽管需求的数量不断增加,但是如果建立环境本体、书写需求、推导系统行为、进行一致性/完整性检测和修改到规则生成完毕,这个过程所花费的总时间渐渐趋于稳定的话,就能够说明,在需求规模到达一定程度后,就可以基本忽略建立环境本体对效率的影响.因此,我们设计了10 个实验,编号1 到10,分别统计了在10 条、30 条、50 条、100 条、200 条、300 条、500 条、800条、1 000 条、1 200 条需求的情况下,总时间(建立环境本体的时间与上述步骤时间之和)与需求条数的比值,即平均每条需求需要花费的时间,实验结果如图10 所示.

Fig.10 Ratio of total time to number of requirements图10 建立环境本体与上述步骤总时间和需求数量的比值

由图10 可以看出,当需求数量上升时,总时间与需求数的比值会逐渐地趋于稳定,也就是说,建立环境本体的时间越来越短,甚至会趋于0,其原因有二:一是领域专家越来越熟悉环境本体的构建,构建环境本体会越来越快;二是同一个领域中很多元素可以复用.例如,一个智能家居物联网系统,当用户撰写10 条需求时,环境本体涉及的被控制实体只有灯、窗户、窗帘,而当用户撰写50 条需求时,环境本体涉及的被控制实体有灯、窗帘、窗户、空调和电视,那么灯、窗户、窗帘这部分的环境本体是可以复用的,这就减少了构建环境本体的时间.受这两方面的影响,建立环境本体的时间被分摊到了越来越多的需求中,逐渐变得可以忽略不计.

需要注意的是,本文方法的正确执行依赖于正确的环境本体.若环境本体出现错误,那么本文方法的正确性也将受到影响.如错误地添加了一个不该存在的环境实体,则在检测完整性时,会错误地将一些没有问题的需求判断为状态不完整;若环境本体中的迁移出现错误,如某个迁移条件写错,则在根据环境本体推导系统行为时,有可能会找不到对应的系统行为,导致出错.事实上,在第5.1 节的用户调研中,已经出现了这样的问题.专业组的一名用户花费了14 分钟进行需求的修改,这在有本文方法提示错误的情况下,已经是很长的时间了.经过询问发现,其在修改过程中发现自己的环境本体建立错误,因此重新建立了环境本体,再对需求进行了更改,所以耗时较长.所以,在构建环境本体时,强调两点:环境本体应该为领域专家构建;环境本体建好之后应该进行同行审查,尽量降低错误的可能性.

6 相关工作

与本文相关的工作包括物联网系统的需求获取方法、需求的一致性与完整性检测以及TAP 的一致性与完整性检测方法.目前已有一些获取物联网系统需求的工作.如文献[2]介绍了一套制定和规范物联网系统需求的方法,物联网系统的需求规格说明包括:领域模型、描述目标及其关系的目标视图以及用UML 图描述的目标规范(goals’ specification).它采用面向目标的方法理念[14],将需求指称到目标上,比较主观,而我们采用的基于环境建模的需求工程理念,将需求指称到环境设备的状态变化上,比较客观.另外,其领域模型与我们的环境本体一样,都属于领域知识,但它只用在需求获取上,没有用在一致性、完整性的检测上.还有一些工作侧重在物联网的非功能需求上,例如,文献[15]基于i*框架[16],在物联网系统的开发早期对安全与隐私需求进行捕获.文献[17]则基于K-model,允许开发者根据模版编写JSON 形式的代码,然后通过这些代码撰写、修改非功能需求.本文的需求涉及服务需求和功能需求,并未涉及非功能需求.

关于需求的完整性与一致性,也已有很多工作.文献[18]阐述了不一致、不完整的需求将会给软件开发带来的灾难性后果,并且给出了度量软件需求规格说明(SRS)完整性、一致性的指标,但其完整性、一致性需要人工去保障;文献[19]进行了一致性自动检测,它将需求表示为SCR 表格符号,将软件系统表示为有限状态自动机,并通过静态分析方法自动检测其一致性;文献[20]使用一种基于状态的需求规范语言——RSML 来表示需求,并利用RSML 的特性,对其进行了完整性与一致性的分析;文献[21]为了提高需求的完整性,提供了一个自然语言处理工具,撰写需求时,该工具会自动提示可能会用到的术语或关系,帮助需求工程师发现相关的概念和交互,从而更准确地撰写需求;文献[22]基于障碍分析,将模型检测和机器学习相结合,识别、评估和解决可能阻碍系统目标的异常情况,从而产生符合完整性的需求.这些方法既没有用在物联网系统中,不支持用户编程,也没有使用环境知识进行检测.

也有一些工作是基于知识进行需求一致性与完整性检测的.例如,文献[8]提出了一种基于知识的需求工程过程方法以保证需求的一致性和完整性.其作者提出一种基于框架本体和生产规则的混合模型来表示系统需求,将本体框架与生产规则结合在一起,从而对需求的一致性、完整性进行检测;文献[23]提出的框架使用专家代理来协助用户进行需求定义,该框架使用知识库和案例库来帮助用户定义一套符合完整性和一致性的系统需求,它允许控制权在用户和专家代理之间来回切换,为需求编写提供了协作媒介;文献[24]给出了一种本体驱动的基于目标的需求工程元模型,该模型基于推理技术,结合了本体一致性检测与规则驱动的完整性测试,既可以用来捕获需求,也可以度量演化中的需求模型的正确性与覆盖度.这些基于知识的方法与本文有相似之处,本文的环境本体其实也是知识,但本文的环境本体是关于物联网系统的环境知识.

还有很多需求的一致性检测是基于模式语言的形式化及形式化验证方法.文献[25]使用规范模式系统形式的受限制自然语言来描述系统需求,然后自动地将其转换为时间计算树逻辑,再转换为一阶逻辑公式,使用Z3对其执行SMT 分析,检测需求是否一致;文献[26]使用BTC 模式表示需求[27],为了最小化分析成本,它使用了有界模型检测方法来检测一致性;文献[28]定义了一种名为SafeNL 的安全需求模式语言,以类自然语言的方式表达需求,然后将其自动转换为时钟约束规范语言,通过有界模型检测的方法检测安全需求的一致性;文献[29]为简化通用模式提出了新的形式化一致性概念,即偏序一致性.偏序一致性可识别系统的关键案例,并验证这些案例是否会引起需求之间的冲突.该文首先使用计数自动机对简化通用模式表示的需求进行形式化建模,然后对偏序一致性进行了形式化的定义,给出了检测需求模型是否违背偏序一致性的方法;文献[30]提出了一种针对汽车系统的结构化需求撰写语言,它使用汽车系统的本体来提供词法和句法的标准,将需求的一致性检测转换为一个布尔命题的证明,然后使用定理证明的方法来检测需求一致性.这些方法中的模型检测和定理证明,都是重量级的形式化方法,效率难以保证,且返回结果难以为一般用户所理解.

现在已有一些工作采用形式化方法对TAP 规则进行一致性检测.例如,文献[7]中的AutoTap,允许用户使用TAP 规则来描述需求,也允许用户定义系统必须满足的属性.AutoTap 将用户书写的规则和属性转换为LTL 公式,使用模型检测的方法检测它们是否有冲突.张秋萍等人开发的工具[31]使用形式化方法,将TAP 规则转换为CTL 与LTL 公式,然后借助NuSMV 工具检测其一致性;文献[32]同样使用了形式化方法,使用线性混合自动机建模物联网系统,然后进行可达性分析来检测其一致性.这些方法都是对TAP 进行检测,这与本文截然不同,本文检测的是系统行为之间是否冲突;而且本文方法实际上是基于规则的方法,效率较高,且使用规模较大.

7 总结与展望

为了实现从服务需求到设备调度程序的自动生成,让终端用户参与物联网系统的开发,本文提出了基于环境建模的TAP 规则生成方法,自动地基于环境模型从服务需求中推导系统行为,检测系统行为的完整性与一致性,并最后转换为TAP 规则.本文构建了环境本体,提供了环境建模的概念和关联,描述了物联网系统中的各个设备的状态、属性、行为以及它们之间的关系.然后,基于环境本体,支持从用户撰写的服务需求推导出系统行为,对其进行一致性、完整性检测以及TAP 规则转换的全过程.本文还对该方法进行了评估,结果表明,其有较好的性能、效率以及准确性;评估还表明,随着需求数的增加,建立环境本体的时间变得可以忽略不计,并能节省很多人工检测一致性、完整性问题的时间.

本文仅关注于物联网系统的功能需求,并未涉及时间、安全性、隐私性、可信赖度等非功能需求.未来工作将考虑对这些非功能需求进行捕获和检测.另外,在环境本体的构建中,目前都还只依赖于领域专家,下一步工作将考虑采用半自动甚至全自动的方法进行构建.