物联网系统按需设备调度规划方法与系统与流程

1.本发明涉及物联网技术领域，更具体的说是涉及物联网系统按需设备调度规划方法与系统。


背景技术：

2.市场上已经出现了各种物联网系统，它们由事件驱动的智能应用程序控制，这些应用程序将感应数据、用户输入或其他来自互联网的外部触发器作为输入，并通过执行器指挥一个或多个智能设备提供不同形式的自动化。如今互联智能设备的数量正在急剧增加，从2010年的125亿台到今年的500亿台。预计在2025年，全球范围内将达到754.4亿台。
3.为了应对这一趋势，在过去几年中，各公司开始向普通消费者推销智能设备，让大众编程。让物联网设备按需求进行调度成为研究的热点问题。但现有的方法都集中在设备调度程序中，如常见的触发
‑
动作编程(tap)。它们通常采用"if trigger，then action"的形式，如"if温度超过25摄氏度，then打开空调"，在tap中，“action”调用设备api，这意味着终端用户必须熟悉设备，才能进行编程。虽然简单的tap规则被成功地用于表达许多带有tap接口的自动化行为，但仍然不足以表达用户各种各样的期望行为。比如，用户需要表达诸如"窗开着和正在下雨不能一起发生"等无法用tap表达的需求。此外，由于智能设备更新速度快，对于tap终端用户来说，不可能熟悉所有的设备，也就难以写出合适的规则。
4.与设备相比，用户的需求特别是高层需求的变化较小。例如，某用户希望室温能保持在25摄氏度，他/她并不关心使用的是哪种设备。因此我们提出描述高层服务需求，将用户的期望指称到设备上，按需生成物联网系统设备调度规划。


技术实现要素：

5.有鉴于此，本发明提供了一种物联网系统按需设备调度规划方法与系统，对环境进行建模，利用用户需求和环境模型知识从服务需求自动推导出系统行为，利用系统行为和设备相关信息导出设备调度指令，将用户的期望指称到设备上，按需生成物联网系统设备调度规划。
6.为了实现上述目的，本发明提供如下技术方案：
7.物联网系统按需设备调度规划方法，具体步骤包括：
8.构建环境模型，所述环境模型包括构建环境本体与设备注册表；
9.根据所述环境本体中的数据参数定义服务请求；
10.利用所述服务请求和用户偏好得到用户请求；
11.根据所述用户请求转换成问题图，基于所述问题图和所述环境本体，得到系统行为；
12.通过所述系统行为生成设备调度指令；
13.根据所述设备调度指令生成情景图进行需求确认。
14.优选的，在上述的物联网系统按需设备调度规划方法中，定义服务请求后还包括：
对请求进行补全；获取物联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。
15.优选的，在上述的物联网系统按需设备调度规划方法中，所述服务请求包括设备相关请求和设备无关请求；根据用户偏好将所述设备无关请求转换成“if
…
then
…”
形式的第二设备相关请求；将所述设备相关请求和所述第二设备相关请求进行综合得到用户请求。
16.优选的，在上述的物联网系统按需设备调度规划方法中，得到系统行为的步骤包括：
17.将所述用户请求结合设备注册表中的api，生成问题图；
18.确定所述问题图中为引用请求或约束请求；
19.再基于环境本体，推导相应的系统行为。
20.优选的，在上述的物联网系统按需设备调度规划方法中，根据所述设备调度指令生成情景图具体步骤：
21.根据服务请求、用户请求以及系统行为，建立对应的关系，生成情景图，其中，服务请求、用户请求以及系统行为采用不同节点进行表示，彼此之间通过带向箭头连接，用来表征对应的关系。
22.物联网系统按需设备调度规划系统，包括：
23.模型构建模块，用于获取环境本体与设备注册表；
24.服务请求获取模块，用于根据所述环境本体中的数据参数定义服务请求；
25.用户请求获取模块，利用所述服务请求和用户偏好得到用户请求；
26.系统行为获取模块，根据所述用户请求转换成问题图，基于所述问题图和所述环境本体，得到系统行为；
27.设备调度指令生成模块，通过所述系统行为生成设备调度指令；
28.情景图生成模块，根据所述设备调度指令生成情景图；
29.用户确认模块，生成的情景图发送给用户端进行确认。
30.优选的，在上述的物联网系统按需设备调度规划系统中，还包括：请求补全模块，用于获取物联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。
31.优选的，在上述的物联网系统按需设备调度规划系统中，服务请求模块包括设备相关请求单元、设备无关请求单元、请求融合单元、用户请求输出单元；所述设备相关请求单元获取设备相关请求，所述设备无关请求单元获取设备无关请求，并将所述设备无关请求转换成“if
…
then
…”
形式的第二设备相关请求；所述请求融合单元将设备相关请求和所述第二设备相关请求进行融合得到用户请求，并通过所述用户请求输出单元输出。
32.优选的，在上述的物联网系统按需设备调度规划系统中，所述系统行为获取模块包括：问题图转换单元、请求判定单元、系统行为推导单元和系统行为输出单元；
33.所述问题图转换单元，将所述用户请求结合设备注册表中的api，生成问题图；所述请求判定单元确定所述问题图中为引用请求或约束请求；
34.系统行为推导单元，根据请求判定单元的判定结果基于环境本体，推导相应的系统行为，并通过所述系统行为输出单元输出所述系统行为。
35.优选的，在上述的物联网系统按需设备调度规划系统中，情景图生成模块包括：服
务请求获取单元、用户请求获取单元、系统行为获取单元、对应关系建立单元和情景图输出单元；
36.所述服务请求获取单元与所述服务请求获取模块连接，所述用户请求获取单元与用户请求输出单元连接；所述系统行为获取单元与所述系统行为输出单元连接；所述服务请求获取单元、所述用户请求获取单元、所述系统行为获取单元均与所述对应关系建立单元连接；并将确定的对应关系发送给所述情景图输出单元输出情景图。
37.经由上述的技术方案可知，与现有技术相比，本发明公开提供了一种物联网系统按需设备调度规划方法与系统，对环境进行建模，利用用户需求和环境模型知识从服务需求自动推导出系统行为，利用系统行为和设备相关信息导出设备调度指令，将用户的期望指称到设备上，按需生成物联网系统设备调度规划。
附图说明
38.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
39.图1附图为本发明的方法流程图；
40.图2附图为本发明的上层环境本体的概念与概念之间的关联示意图；
41.图3(a)
‑
3(c)附图分别为本发明的智能家居领域环境本体中的状态机的实例；
42.图4附图为本发明的问题图的示意图；
43.图5附图为本发明的设备相关用户请求转换成系统行为的示意图；
44.图6附图为本发明的问题图显示界面示意图；
45.图7附图为本发明的情景图显示界面示意图；
46.图8附图为本发明的结构框图。
具体实施方式
47.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
48.本发明的实施例公开了一种物联网系统按需设备调度规划方法，如图1所示，具体步骤包括：
49.s101构建环境模型，环境模型包括构建环境本体与设备注册表；
50.环境本体来提供环境建模的基本概念和概念间的关联，根据是否领域相关，将环境本体分为两类：上层环境本体和领域环境本体。环境本体由领域专家构建，分别为上层环境本体和领域环境本体。
51.上层环境本体：上层环境本体描述通用的环境建模中的概念和关联。物联网系统的环境可以看作是与系统发生交互的一组实体(称之为环境实体)的集合，因此环境实体(environment entity)是环境本体中的最基本的概念。在具体的应用场景中，智能家居中
的灯、窗帘、人、空气等都是环境实体。这些环境实体可以分为两类:
52.被监视的环境实体(monitored entity):这类环境实体仅可被物联网系统以监视的方式获取其状态值，但无法直接改变这些实体的状态，即，实体的状态是自主变化，不以人的意志为转移的。例如，智能家居中涉及到的室内空气、光照等；
53.环境实体的信息由静态的属性及其取值来描述，被监视实体的属性值一般需要通过传感器进行获取，而对于被控制的环境实体，它们都有多个状态，而这些状态之间存在着迁移关系，因此可以用状态机来表示其各个状态之间的转换关系：状态机有节点和边，节点表示被控制实体的状态，边表示状态之间的转换关系，边上的事件则表示状态转移的条件，具体的实例如图3(a)
‑
3(c)所示。
54.被控制的环境实体(controlled entity):对于这类环境实体，不仅可以获取其状态值(即各项属性值)，而且可以向这些环境实体发送事先定义好的指令，以改变其状态。各种嵌入式设备均属于该类实体，如智能家居中的日光灯、窗户、电动窗帘等。而它们的改变既可以是状态也可以是属性值，例如灯既可以用“开、关”来描述，也可以用具体的亮度数值来描述。
55.上层环境本体的各个概念之间还存在着关联，具体如图2所示。
56.领域环境本体：是针对某个具体的领域的环境建模的结果，是对上层环境本体概念和关联在特定领域中的实例化。
57.设备注册表如表1所示，由设备的生产商进行添加，该表包含设备的类型、该类型设备的状态、状态对应的api、状态对应的调度指令以及该状态会产生的影响，以某用户家中的空调为例，其设备类型为“大金空调型号a1”，制热状态对应的api为“hotpulse”，ifttt形式的调度指令为“turn on the air conditionerhot”，会让温度上升；制冷状态对应的api为“coldpulse”，ifttt形式的调度指令为“turn on the air conditioner cold”，会让温度下降。
58.表1
59.设备类型设备状态状态对应api状态作用状态效果灯打开状态灯开脉冲打开灯光线强度 灯关闭状态灯关脉冲关闭灯光线强度
‑
窗户打开状态打开脉冲打开窗户对室内通风
…………………………
60.进一步，假设智能家居领域中包含的环境实体有窗户(window)、窗帘(blind)、灯(bulb)、光照(light)和空气(air)，这些都是环境实体的实例。窗户的属性为windowst，描述窗户的开闭，其取值为wopen或wclosed；窗帘的属性为blindst，描述窗帘的开闭，它的取值是bopen或bclosed；灯的属性为bulbst，描述灯的开关，它的取值是bon或boff；光照的属性为brightness，表示亮度，它的值理论上可以为大于0的任意值；空气的属性为温度(temperature)和湿度(humidity)，temperature表示气温，它的值理论上可以为
‑
273.15摄氏度到正无穷；humidity表示空气的相对湿度，它的值理论上可以为0到正无穷。这些具体的属性和取值分别是属性和值这两个概念的实例。
61.对于每个被控制实体，需要进一步识别其状态机。在智能家居领域中，窗户、窗帘和灯的状态机如图3所示，以灯为例，当其处于bon状态时，表示灯开着，如果此时收到一个
bonpulse事件，则继续开着，如果收到boffpulse事件则关闭；当其处于boff状态时，表示灯关着，如果此时收到一个bonpulse事件，则灯打开，反之如果收到boffpulse事件则仍然关闭。这些都是状态机、事件、状态、迁移概念的具体实例。
62.s102根据环境本体中的数据参数定义服务请求；
63.服务请求是根据环境本体中的各个元素定义的，这些元素包括状态(state)、属性(attribute)、事件(event)和取值(value)，根据这些元素，定义了如下的服务需求模版，这些服务需求模版都是贴近用户的感受的(基于历史数据获取)：
64.模板1：state should always be active：某个设备的状态必须时刻维持，如服务器的打开状态。
65.模板2：attribute should always be above/below value：某个属性必须高于/低于某个值，如二氧化碳浓度必须低于800ppm，室内相对湿度必须高于70％，等等。
66.模板3：event should never happen：不允许某个事件发生，比如不允许服务器重启。
67.模板4：attribute should never be above/below value：某个属性不能高于/低于某个值。
68.模板5：[state1，state2，
…
]should never occur together：某些状态不能同时发生，如窗户的打开状态与空调的制冷、制热状态。
[0069]
模板6：preferred attribute is value：某个属性维持在一个值，如希望室内温度维持在20摄氏度。
[0070]
模板7：if trigger(for time)then event：当触发某个条件时，执行某一事件，如气温高于30度时开空调制冷。
[0071]
模板8：if trigger(fortime)then state：当触发某个条件时，某一状态必须保持，如气温高于30度时开空调处于制冷状态。
[0072]
模板9：if trigger(fortime)then effect：当触发某个条件时，需要产生某一效果，如气温高于30度时气温降低。
[0073]
s103利用服务请求和用户偏好得到用户请求；
[0074]
服务请求包含设备相关请求与设备无关请求，设备相关请求指直接指定到设备的需求，而设备无关请求则是没有指称到设备的需求，模版1、3、5、7、8都是设备相关请求，其余则是设备无关请求，对于这两类请求，本实施例先根据用户偏好(用户偏好根据用户选择确定)，把设备无关请求都转化为“if
…
then
…”
形式的第二设备相关请求，再使用开源工具autotap对所有的设备相关需求进行综合，得到全部为“if
…
then
…”
形式的用户请求。
[0075]
为了将设备无关请求转换为“if
…
then
…”
形式的第二设备相关请求，用户首先需要选择用户偏好，如节能、最佳性能、随机等，选择完成以后，本实施例会根据偏好将设备无关请求指称到设备上，对不同的设备无关请求，转换方式也有所不同：
[0076]
(1)对于模版2和模版4，为了让某一属性必须(不能)高于(低于)某个值，只需要根据设备注册表，选择能够让这个属性上升(下降)的设备状态即可，如果有多个这样的设备状态，则根据用户的偏好选择对应的设备状态即可。
[0077]
(2)对于模版6，为了让某一属性维持在某个值，只需要让属性大于该值时选择让这个属性下降的设备状态，小于该值时选择让这个属性上升的设备状态即可。同样，如果有
多个设备状态能造成这种上升(下降)，则根据用户的偏好选择对应的设备状态即可。
[0078]
(3)对于模版9，设备注册表中会记录不同设备的不同状态会造成的效果，只需根据用户偏好选择对应的设备，即可将其转换为“if
…
then
…”
形式的设备相关需求。
[0079]
将设备无关请求转换为“if
…
then
…”
形式第二设备相关请求之后，使用开源工具autotap对全部的设备相关需求进行综合。autotap是芝加哥大学开发的一个开源工具，其输入为tap规则与这些规则需要满足的性质(用ltl表示)，输出为满足这些性质并且不会破坏原有规则的tap规则。
[0080]
因此，先将模版1、3、5对应的请求转换为ltl公式描述的性质：模板1表示某个状态需要时刻维持，设该状态为s，则其对应的ltl公式为“g s”；模板3表示某个事件不能发生，设该事件为e，则其对应的ltl公式为“！f e”；模板5表示多个状态不会同时保持，假设这些状态为s1,s2，
…
，s
n
，则其对应的ltl公式为“！f(s1/\s2/\
…
/\s
n
)”。
[0081]
然后，使用autotap对全部的设备相关请求进行综合：按照上述方法将模版1、3、5对应的请求改写为ltl公式描述的性质输入，并同时将其余“if
…
then
…”
形式的设备相关请求作为tap规则输入，即可得到全部为“if
…
then
…”
形式的设备相关用户请求。
[0082]
s104根据用户请求转换成问题图，基于问题图和环境本体，得到系统行为；
[0083]
在从用户请求推导系统行为时，采用问题图作为载体。问题图的概念如下：
[0084]
问题图是问题框架方法需求描述的结果，在本发明中用来承载用户服务请求和软件行为。图5给出了问题图的简单示例，软件问题就是要指定一个待开发系统(控制机器controllermachine)来监视、控制问题领域(空气air和空调air conditioner)，以满足需求(调节温度adjust temperature)。问题领域与机器之间的连接称为接口(一种交互)，指明了它们之间共享的现象，如控制机器与空调之间共享现象开脉冲(onpulse)和关脉冲(offpulse)。接口由一方发起，用“发起者！{内容}”表示，内容可以是现象中的事件、状态或取值。需求表示为一段自然语言描述的期望，实际指称为人们期望在问题领域上发生的改变，如期望室温t>30，或者空调(air conditioner)打开(on)或关闭(off)等，这种期望现象称为需求现象。对那些只能观察而无法控制的需求现象的引用称为需求引用:如对于室温，只能观察、引用，而不能控制；而对那些可以控制的需求现象的约束称为需求约束:如对于空调，人们可以控制它的开关。需求引用和需求约束都可以表示为接口交互的形式。
[0085]
在问题图的左右两边，分别承载了用户服务请求和软件行为。其中用户服务请求用需求现象及其之间的关系描述，表示在问题图右边的需求引用和约束处。如图4中右边虚线处a和c中的需求现象，要求当温度高于30度、低于20度时，空调要处于打开和关闭状态，这是用户需要的，是用户服务请求。软件行为用规约现象及其现象之间的关系描述，表示在问题图左边的接口处。如图5左边实线接口a，b处，共享现象要求当温度高于30度时，控制器发出开空调的脉冲，而温度低于20度时则发出关空调的脉冲，这规定了软件系统行为。需要注意的是，问题图中并没有信息指导从用户服务请求中导出软件系统行为，这种导出需要领域知识，本文使用环境本体来描述这些领域知识。
[0086]
为了将“if
…
then
…”
形式的设备相关用户请求转换为系统行为，本装置使用问题图作为中间载体。系统行为的推导分为两步。第一步，将设备相关用户请求标记到问题图中。每一条设备相关用户请求都能对应一个问题图，其中的信息可以定义问题图的右边部分。具体的对应如下:首先是环境实体与问题领域的对应，在“if<entity.trigger>then<
entity.state>”中，entity就是与系统交互的环境实体，它们就是问题图的问题领域，就像图5中的服务请求“if air.temperature>30then window.wopen”的air和window可以直接转换成问题领域air和window。其次，trigger和state与需求引用和约束中的现象相对应，trigger作为需求的条件，表示对需求的引用，可以直接画为需求引用，而state则是用户期望看到的现象，是对需求的约束，可以直接画为需求约束，现象发起者应该是其前面的entity。如图5中air.temperature>30就可以直接转为需求引用air！{temperature>30}，window.wopen可以直接转为需求约束window！{wopen}。椭圆形需求里面可以直接标注标号即可，如图5中的req1。
[0087]
第二步则需要根据环境本体，推导相应的系统行为，即定义问题图的左边接口部分。对于简单服务请求，即entity.trigger中没有与或关系的，考虑trigger和state的不同实体类型，分别处理:
[0088]
无论entity.trigger中的entity是被监视实体还是被控制实体，都将需求引用中的条件直接拷贝过来，就像图5中的m和air之间的接口；
[0089]
对于entity.state中的实体，就需要通过其状态机，查找触发状态state的事件，将其作为共享现象放在接口中，而且这个接口必须是软件发出的，如图5中，window状态机里的状态wopen的触发事件为wopenpulse，则接口就可以定义为m！{wopenpulse}。
[0090]
而针对包含与或关系的复杂用户服务请求，其处理如下:
[0091]
如果是与关系连接了多个entity.trigger，那对于每一个entity.trigger，该entity对应的问题领域都要与请求通过需求引用相连，然后在需求引用上根据trigger添加需求现象；
[0092]
如果是或关系连接，即“if a||b then entity.state”形式的请求，这表示如果a发生或者b发生，entity都应该处于state状态，那么如果将a和b拆开，使得这条请求变为两条，即“if athen entity.state”和“if b then entity.state”，代表的含义也是一样的。比如“ifair.temperature<25||air.humidity>25then window.wclosed”，就可以拆为“ifair.temperature<25then window.wclosed”和“ifair.humidity>25then window.wclosed”。因此，对这种带有或关系的请求，我们将其拆解为两句，分别转换为问题图。
[0093]
据此得到问题图后，可以从中生成系统行为：首先确定问题图中的问题领域中是对应需求引用还是需求约束，若为引用，则其问题领域的接口对应if里面的内容，如果有多个引用则使用“and”进行连接；若为约束，则其问题领域的接口对应then里面的内容。如图5中问题图的问题领域air是需求引用，则其接口“air！{temperature>30}”为if里的内容，而问题领域window对应的是需求约束，则其接口“m！{wopenpulse}”为then里的内容，由此生成系统行为:ifair.temperature>30thenm.wopenpulse。
[0094]
例如，基于环境本体，将这些设备相关请求转换为问题图：以“if air.humidity>100then window.wclosed”为例，其涉及环境实体空气与窗户，因此它们就是问题图的问题领域；于是问题图的需求引用就是湿度高于100，需求约束就是窗户处于关闭状态；空气是被监视实体，它的湿度属性由湿度传感器监视，因此空气与湿度传感器相连，且与传感器相连的接口上的现象也是湿度高于100；从环境本体中可以发现只有接收到关脉冲窗户才会处于关闭状态，因此与窗户相连的接口上的现象是控制器发出关脉冲，其他的设备相关需
求转换为问题图的方式也不外乎此。对于这些需求，实施例生成的问题图如图6所示。
[0095]
s105通过系统行为生成设备调度指令；
[0096]
在生成系统行为后，可以根据设备注册表生成ifttt设备调度指令：将设备注册表中的api、usage条目进行对照，然后替换系统行为中的action即可。如例的系统行为“ifair.temperature>30thenm.wopenpulse”，wopenpulse对应指令open the window，因此将系统行为中的“wopenpulse”替换为指令open the window，就可以得到ifttt设备调度指令“ifair.temperature>30then open the window”。
[0097]
s106根据设备调度指令生成情景图进行需求确认；
[0098]
为了让用户能够直观地对需求进行确认，本装置使用情景图来展示系统行为是否满足用户撰写的服务需求。情景图有蓝色、绿色、粉色、灰色和橙色节点，其中蓝色节点代表系统行为，绿色节点代表问题图中的远程领域传递的现象，橙色节点代表设备相关用户需求，灰色节点代表设备，而粉色节点则是用户撰写的服务需求。情景图的生成分为三个步骤：
[0099]
生成粉色节点：在用户撰写服务需求后，本装置会生成情景图的服务需求元素，即情景图中的粉色节点。粉色节点代表了服务需求，因此只需要将用户撰写的与装置自动补全的服务需求分别写到粉色节点上即可。
[0100]
生成橙色节点和灰色节点：在生成设备相关用户需求后，本装置会生成情景图的用户需求元素和设备元素，即情景图中的橙色和灰色节点。灰色节点代表了设备，因此只需要遍历所有设备相关用户需求，将其中涉及到的设备分别写到灰色节点上即可；橙色节点代表了设备相关用户需求，它们之间的连线表示了用户期望的先后顺序，如用户期望温度传感器的示数大于30，表明温度高于30摄氏度，因此窗户需要处于打开的状态。设备相关用户需求中，“if”之后的内容是最先发生的，因此它们是橙色节点的起点，而“then”之后的内容发生在“if”之后，因此这些起点会指向“then”之后的内容。最后，每个橙色节点都会指向与其相关的设备，以及它所满足的服务需求，表明设备相关用户需求能够满足服务需求。
[0101]
生成蓝色节点和绿色节点：在生成系统行为后，本装置会生成情景图中的蓝色和绿色节点。蓝色节点代表了系统行为，它们之间的连线表示系统行为的先后顺序，如温度传感器的示数高于30，表明系统要发出开窗的脉冲。系统行为中，“if”之后的内容是最先发生的，其对应的系统行为就是蓝色节点的起点，而“then”之后的内容发生在“if”之后，因此这些起点最终会指向“then”之后的内容。绿色节点代表了问题图中远程领域传递的现象，远程领域指问题图中不直接与machine连接的问题领域，主要是一些被监视实体，因此系统行为的起点首先会指向这些绿色节点，再指向“then”之后的内容对应的系统行为，并最终指向橙色节点，表明系统行为满足设备相关用户需求，从而满足服务需求。另外，橙色节点和蓝、绿色节点之间的绿色连线代表同步关系，即两者内容一致。
[0102]
以设备无关的服务请求“light.brightness should never be below500”为例，它本身是一个粉色节点，与它相连的橙色节点，表示设备相关需求，即光照传感器的读数小于500，表明光照强度小于500，因此灯需要处于打开的状态；与它相连的蓝色和绿色节点表示系统行为，即光照传感器的读数小于500，表明光照强度小于500，因此软件需要发出开灯的脉丛；而灰色节点灯则是与其相关的设备。本实施例生成的情景图如图7所示。
[0103]
为了进一步优化上述技术方案，定义服务请求后还包括：对请求进行补全；获取物
联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。
[0104]
用户根据模版撰写服务请求之后，常常会遗漏一些的服务需求，即在无人的时候关掉设备。因此，用户撰写完服务需求后，本装置会读取环境本体中所有设备的初始状态，在没人超过30分钟后将所有设备都置为初始状态，从而对用户撰写的需求进行补全。
[0105]
物联网系统按需设备调度规划系统，如图8所示，包括：
[0106]
模型构建模块，用于获取环境本体与设备注册表；
[0107]
服务请求获取模块，用于根据环境本体中的数据参数定义服务请求；
[0108]
用户请求获取模块，利用所述服务请求和用户偏好得到用户请求；
[0109]
系统行为获取模块，根据用户请求转换成问题图，基于问题图和环境本体，得到系统行为；
[0110]
设备调度指令生成模块，通过系统行为生成设备调度指令；
[0111]
情景图生成模块，根据设备调度指令生成情景图；
[0112]
用户确认模块，生成的情景图发送给用户端进行确认。
[0113]
为了进一步优化上述技术方案，还包括：请求补全模块，用于获取物联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。
[0114]
为了进一步优化上述技术方案，服务请求模块包括设备相关请求单元、设备无关请求单元、请求融合单元、用户请求输出单元；设备相关请求单元获取设备相关请求，设备无关请求单元获取设备无关请求，并将设备无关请求转换成“if
…
then
…”
形式的第二设备相关请求；请求融合单元将设备相关请求和第二设备相关请求进行融合得到用户请求，并通过用户请求输出单元输出。
[0115]
为了进一步优化上述技术方案，系统行为获取模块包括：问题图转换单元、请求判定单元、系统行为推导单元和系统行为输出单元；问题图转换单元，将用户请求结合设备注册表中的api，生成问题图；请求判定单元确定问题图中为引用请求或约束请求；系统行为推导单元，根据请求判定单元的判定结果基于环境本体，推导相应的系统行为，并通过系统行为输出单元输出系统行为。
[0116]
为了进一步优化上述技术方案，情景图生成模块包括：服务请求获取单元、用户请求获取单元、系统行为获取单元、对应关系建立单元和情景图输出单元；服务请求获取单元与服务请求获取模块连接，用户请求获取单元与用户请求输出单元连接；系统行为获取单元与系统行为输出单元连接；服务请求获取单元、用户请求获取单元、系统行为获取单元均与对应关系建立单元连接；并将确定的对应关系发送给情景图输出单元输出情景图。
[0117]
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
[0118]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

技术特征：
1.物联网系统按需设备调度规划方法，其特征在于，具体步骤包括：构建环境模型，所述环境模型包括构建环境本体与设备注册表；根据所述环境本体中的数据参数定义服务请求；利用所述服务请求和用户偏好得到用户请求；根据所述用户请求转换成问题图，基于所述问题图和所述环境本体，得到系统行为；通过所述系统行为生成设备调度指令；根据所述设备调度指令生成情景图进行需求确认。2.根据权利要求1所述的物联网系统按需设备调度规划方法，其特征在于，定义服务请求后还包括：对请求进行补全；获取物联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。3.根据权利要求1所述的物联网系统按需设备调度规划方法，其特征在于，所述服务请求包括设备相关请求和设备无关请求；根据用户偏好将所述设备无关请求转换成“if
…
then
…”
形式的第二设备相关请求；将所述设备相关请求和所述第二设备相关请求进行综合得到用户请求。4.根据权利要求1所述的物联网系统按需设备调度规划方法，其特征在于，得到系统行为的步骤包括：将所述用户请求结合设备注册表中的api，生成问题图；确定所述问题图中为引用请求或约束请求；再基于环境本体，推导相应的系统行为。5.根据权利要求1所述的物联网系统按需设备调度规划方法，其特征在于，根据所述设备调度指令生成情景图具体步骤：根据服务请求、用户请求以及系统行为，建立对应的关系，生成情景图，其中，服务请求、用户请求以及系统行为采用不同节点进行表示，彼此之间通过带向箭头连接，用来表征对应的关系。6.物联网系统按需设备调度规划系统，其特征在于，包括：模型构建模块，用于获取环境本体与设备注册表；服务请求获取模块，用于根据所述环境本体中的数据参数定义服务请求；用户请求获取模块，利用所述服务请求和用户偏好得到用户请求；系统行为获取模块，根据所述用户请求转换成问题图，基于所述问题图和所述环境本体，得到系统行为；设备调度指令生成模块，通过所述系统行为生成设备调度指令；情景图生成模块，根据所述设备调度指令生成情景图；用户确认模块，生成的情景图发送给用户端进行确认。7.根据权利要求6所述的物联网系统按需设备调度规划系统，其特征在于，还包括：请求补全模块，用于获取物联网系统中所有设备的初始状态，无服务请求时长超过阈值恢复初始状态。8.根据权利要求6所述的物联网系统按需设备调度规划系统，其特征在于，服务请求模块包括设备相关请求单元、设备无关请求单元、请求融合单元、用户请求输出单元；所述设备相关请求单元获取设备相关请求，所述设备无关请求单元获取设备无关请求，并将所述
设备无关请求转换成“if
…
then
…”
形式的第二设备相关请求；所述请求融合单元将设备相关请求和所述第二设备相关请求进行融合得到用户请求，并通过所述用户请求输出单元输出。9.根据权利要求8所述的物联网系统按需设备调度规划系统，其特征在于，所述系统行为获取模块包括：问题图转换单元、请求判定单元、系统行为推导单元和系统行为输出单元；所述问题图转换单元，将所述用户请求结合设备注册表中的api，生成问题图；所述请求判定单元确定所述问题图中为引用请求或约束请求；系统行为推导单元，根据请求判定单元的判定结果基于环境本体，推导相应的系统行为，并通过所述系统行为输出单元输出所述系统行为。10.根据权利要求9所述的物联网系统按需设备调度规划系统，其特征在于，情景图生成模块包括：服务请求获取单元、用户请求获取单元、系统行为获取单元、对应关系建立单元和情景图输出单元；所述服务请求获取单元与所述服务请求获取模块连接，所述用户请求获取单元与用户请求输出单元连接；所述系统行为获取单元与所述系统行为输出单元连接；所述服务请求获取单元、所述用户请求获取单元、所述系统行为获取单元均与所述对应关系建立单元连接；并将确定的对应关系发送给所述情景图输出单元输出情景图。
技术总结
本发明公开了物联网系统按需设备调度规划方法，应用于物联网技术领域，具体步骤包括：构建环境模型，环境模型包括构建环境本体与设备注册表；根据环境本体中的数据参数定义服务请求；利用服务请求和用户偏好得到用户请求；根据所述用户请求转换成问题图，基于所述问题图和所述环境本体，得到系统行为；通过所述系统行为生成设备调度指令；根据所述设备调度指令生成情景图进行需求确认。本发明公开提供了一种物联网系统按需设备调度规划方法与系统，对环境进行建模，利用用户需求和环境模型知识从服务需求自动推导出系统行为，利用系统行为和设备相关信息导出设备调度指令，将用户的期望指称到设备上，按需生成物联网系统设备调度规划。规划。规划。


技术研发人员：金芝 陈小红 边寒
受保护的技术使用者：华东师范大学
技术研发日：2021.03.18
技术公布日：2021/6/29