CN104410568B - 一种智能家居语义网关的设计方法 - Google Patents
一种智能家居语义网关的设计方法 Download PDFInfo
- Publication number
- CN104410568B CN104410568B CN201410619121.4A CN201410619121A CN104410568B CN 104410568 B CN104410568 B CN 104410568B CN 201410619121 A CN201410619121 A CN 201410619121A CN 104410568 B CN104410568 B CN 104410568B
- Authority
- CN
- China
- Prior art keywords
- data
- semantic
- rdf
- intelligent home
- contentprovider
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 238000013461 design Methods 0.000 title claims abstract description 13
- 238000013519 translation Methods 0.000 claims abstract description 8
- 238000013480 data collection Methods 0.000 claims description 12
- 241001269238 Data Species 0.000 claims description 9
- 238000009434 installation Methods 0.000 claims description 6
- 230000027455 binding Effects 0.000 claims description 4
- 238000009739 binding Methods 0.000 claims description 4
- 101100031807 Rattus norvegicus Paics gene Proteins 0.000 claims description 3
- 238000011161 development Methods 0.000 abstract description 7
- 238000012546 transfer Methods 0.000 abstract description 2
- 238000004378 air conditioning Methods 0.000 description 26
- 230000003287 optical effect Effects 0.000 description 15
- 238000005516 engineering process Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 238000004458 analytical method Methods 0.000 description 7
- 238000011160 research Methods 0.000 description 7
- 230000018109 developmental process Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 5
- 230000004927 fusion Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000003780 insertion Methods 0.000 description 4
- 230000037431 insertion Effects 0.000 description 4
- 238000010276 construction Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000004888 barrier function Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 238000004134 energy conservation Methods 0.000 description 1
- 238000005286 illumination Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 241000894007 species Species 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
一种智能家居语义网关的设计方法，涉及计算机数据传输和处理领域，基于Android平台，具体步骤为：第一、构建数据汇集系统，用于保存智能家居设备数据；第二、为访问智能家居设备的应用程序建立ContentProvider接口；第三、构建智能家居设备的语义本体；第四、为每个智能家居设备开发对应的语义数据转换接口；第五、启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。本发明能够使得智能家居网络开发人员方便高效地构建语义网关，降低开发难度，部署灵活，输出的智能家居语义数据能够由浏览器直观显示。
Description
技术领域
本发明涉及计算机数据传输和处理领域，具体涉及一种智能家居语义网关的设计方法。
背景技术
智能家居(Smart Home)，是以住宅为平台，利用综合布线技术、网络通信技术、智能家居-系统设计方案安全防范技术、音视频技术将家居生活有关的设施集成，构建高效的住宅设施与家庭日程事务的管理系统，提升家居安全性、便利性、舒适性、艺术性，并实现环保节能的居住环境。与普通家居相比，智能家居不但具有传统的居住功能，兼备建筑、网络通信、管理为一体的高效、舒适、安全、便利、环保的居住环境，还提供全方位的信息交互功能。智能家居概念的起源很早，但一直未有具体的建筑案例出现，直到1984年美国联合科技公司将建筑设备信息化、整合化概念应用于美国康乃迪克州哈特佛市的CityPlaceBuilding时，才出现了首栋的“智能型建筑”，从此揭开了全世界争相建造智能家居的序幕。
智能家居网关是智能家居系统的“大脑”，它不仅具有数据信息采集功能，而且还具有数据分析处理的能力，实现了对家庭网络设备的智能化统一管理。但是，由于家居设备种类、输出数据结构、信息传输模式和通信组网方式等千变万化、各不相同，系统所表现出的数据格式、符号以及语法就存在着巨大差异，难以做到语义融合和基于统一语义的正确推理。大量异构数据的理解、融合和互操作成为家居数据空间凸显的技术难题，这严重制约了智能家居行业的发展。为此，我们在智能家居网关中引入了语义网技术来保证网络各节点语义一致性。
传统的智能家居网关是一个基于关系数据库的简单应用，把智能家居网络中的各设备收集的信息存到数据库中。用户在使用这些数据时需要清楚这些数据表达的语义。比如，某温度传感器向网关报告当前温度值是25摄氏度，然而，用户在数据库中看到的只是25这个数，并不是“当前温度值是25摄氏度”这个完整的语义。本发明要解决的就是在智能家居网关中提供家居设备数据的完整语义描述，使用户不需要了解家居设备厂商对数据的定义细节，在此基础上可以方便开发功能丰富的智能家居应用，实现类似于“若当前房间温度高于27摄氏度，则启动空调制冷”这样的语义规则。这种语义网方法能够提高智能家居网络对网内各设备采集的信息的分析和处理能力，是新一代互联网的一个发展方向。
吉林大学硕士生李程贵于2012年发表的学位论文“一种基于语义融合的智能家居系统的研究与实现”，南京航空航天大学硕士生李辉于2012年发表的学位论文“基于MAS和OWL本体的智能家居系统的研究”，这两篇文章都提出基于Jena的基于语义融合智能家居系统总体设计方案，而Jena是由惠普实验室开发的语义网应用开发框架。该方案在语义推理上较成功，但是缺少从非语义数据到有语义数据的直观转换方法。
北京邮电大学硕士生宋劼于2011年发表的学位论文“基于语义的智能家居管理系统关键技术研究”，该文对智能家居环境中的场景进行分析，用语义推理的方法来描述场景规则，但缺乏实现语义推理的实现框架及步骤，同时该文也缺少从非语义数据到有语义数据的直观转换方法。
Yuwei Zhang、Zhiqiang Wei和Yongquan Yang发表于2012InternationalConference on Computer Science and Service System(CSSS)会议上的论文“Ontologydescription of smart home appliance based on semantic web”(基于语义网的智能家居设备的本体描述)，该文提出了基于语义网对智能家居设备建立本体，分别构建了三个本体：属性本体、状态本体及服务本体。该方法可以实现异构数据的设备间进行信息的交换和数据的共享，但具有较大的局限性，因为实际的智能家居设备产生的数据差异性较大，难以用少数几个本体完全描述。另外，该文也缺少从非语义数据到有语义数据的直观转换方法。
发明内容
本发明的目的在于提供一种智能家居语义网关的设计方法，解决智能家居网络系统中缺乏语义数据的问题。
本发明的具体方案是：
一种智能家居语义网关的设计方法，基于Android平台，具体步骤如下：
步骤1：构建数据汇集系统，用于保存智能家居设备数据；
步骤2：为访问智能家居设备的应用程序建立ContentProvider接口；
步骤3：构建智能家居设备的语义本体；
步骤4：为每个智能家居设备开发对应的语义数据转换接口；
步骤5：启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。
所述的Android平台为Android平板平台或者Android智能手机平台。
所述步骤1具体为在Android平台上创建保存智能家居设备数据的Sqlite数据库Hadb，根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据，同时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平台的数据库中。
所述步骤2还包括定义访问数据库的资源的路径，即通用资源标识URI。
所述步骤2中建立ContentProvider接口为：先定义ContentProvider类，使该类继承Android提供的ContentProvider基类；再注册定义的ContentProvider类，在Manifest.xml配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识的URI。
所述步骤3具体为描述设备类型、对象属性、数据属性，生成对应的本体描述文件，即是owl文件。
所述步骤4，为每个智能家居设备开发对应的语义数据转换接口是基于Android语义服务框架进行开发的。
所述步骤4Android语义服务框架下，为每一种智能家居设备构建一个RDFProvider，RDF Provider需要访问对应的Sqlite数据表，实现将智能家居设备数据暴露为RDF语义数据，并自动地注册到RDF ContentResolver上。
所述RDF Provider为RDF TH Provider、RDF LightSensor Provider或RDF AirCProvider。
所述步骤5包括在智能家居语义网关上安装语义Web服务器RDF Server。
本发明的有益效果是：能够使得智能家居网络开发人员方便高效地构建语义网关，降低开发难度，部署灵活，输出的智能家居语义数据能够由浏览器直观显示，由RDF语言表达的形式化语义可以使机器真正的理解智能家居设备所采集到的数据的具体含义，从而为开发需要语义融合、语义推理的更高级应用(如智能家居场景控制)提供基础。
附图说明
图1为基于语义网关的智能家居网络部署示意图(三个设备表示智能家居，从左到右分别为空调、温湿度传感器和光照传感器)。
图2为本发明中智能家居语义网关的结构示意图。
图3为网关上的数据采集和存储中间件的流程图。
具体实施方式
本发明采用Android平板或Android智能手机作为实现智能家居网络语义网关的平台。由于Android平台具有现成的Wifi，蓝牙无线能力，而智能家居设备组成的网络目前大多采用Wifi或蓝牙，方便了智能家居网络的集成。并且，Android平台成本比专门开发的智能家居网关成本要低得多，Android操作系统上丰富的软件资源降低了系统开发的难度。
具体设计步骤如下：
第一步、构建与传统无语义网关类似的数据汇集系统，即创建保存智能家居设备数据的数据库，以及把智能家居网络中的各设备发给网关的数据进行解析并存入到数据库中的中间件。这些数据是不含有语义的。需要通过下面的构建语义本体以及数据语义输出等步骤才能得到有语义的智能家居设备数据。
第二步、为存储智能家居设备数据的Sqlite数据库所在的应用程序建立相应的ContentProvider接口，供其他应用程序访问智能家居设备的数据。
第三步、构建智能家居设备的语义本体，描述设备类型、对象属性、数据属性，生成对应的本体描述文件(.owl文件)。OWL文件是采用Web本体语言(Web Ontology Language，OWL)刻画语义本体的文件。智能家居设备的本体描述文件刻画智能家居设备中涉及到的词汇以及词汇之间的关系，是输出语义数据的基础。
第四步、在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开发对应的语义数据转换接口。
第五步、启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。
其中，第一步具体为在Android平台上创建保存智能家居设备数据的Sqlite数据库Hadb，根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据，同时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平台的数据库中。
第二步还包括还包括定义了访问数据库的资源的路径，即通用资源标识URI。具体为建立ContentProvider接口为：先定义ContentProvider类，使该类继承Android提供的ContentProvider基类；再注册定义的ContentProvider类，在Manifest.xml配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识的URI。
第三步具体为描述设备类型、对象属性、数据属性，生成对应的本体描述文件，即是owl文件。
第四步具体为在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开发对应的语义数据转换接口。在Android语义服务框架下，为每一种智能家居设备构建一个RDF Provider，RDF Provider需要访问对应的Sqlite数据表，实现将智能家居设备数据暴露为RDF语义数据，并自动地注册到RDF ContentResolver上。
第五步还包括在智能家居语义网关上安装语义Web服务器RDF Server。
图1为基于语义网关的智能家居网络部署示意图。如图1所示，某智能家居网络部署中包含三个智能家居设备和一个网关。三个智能家居设备分别是空调、温湿度传感器、光照传感器，其中空调和温湿度传感器采用Wifi方式接入家居网络，光照传感器通过蓝牙方式接入网络。网关是一个Android平板，运行Android操作系统，实现语义网关功能的组件如图2所示，包括Sqlite数据库、数据采集中间件、设备语义数据转换接口、RDF解析接口以及语义Web服务器。
下面就温湿度传感器、空调和光照传感器三种具体的智能家居设备设计语义网关的具体实施例来详细说明。
实施例1：温湿度传感器。
步骤一：在Android平板上创建保存智能家居设备数据的Sqlite数据库Hadb。根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据。建立Sqlite数据库表tempHum_data，其中含有7个字段，分别代表了每条数据的ID、温度值、温度单位、湿度值、温度单位、采集数据的时间及温湿度传感器的开/关状态。
同时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平板的数据库中。数据采集中间件运行流程图如图3所示。数据采集中间件是一个Android上开发的软件，该软件是一个常驻服务进程，不断监听TCP/IP端口(假设是3467)或蓝牙通讯，获得智能家居设备发来的数据包。例如，本实施例中的温湿度传感器发来以下格式的数据包：0x7e0702010119064914。
包结构如下：
| 包头 | 包长 | 设备类型 | 包类型 | 设备ID | 温度 | 湿度 |
| 1字节 | 1字节 | 1字节 | 1字节 | 1字节 | 2字节 | 2字节 |
数据采集中间件接收到数据包后，根据“包头”来判断一个包的起始字节，包头可以是任何预先定义好的特殊符号，本例中采用0x7e作为包头。然后获取“包长”字段，不同的家居设备上报的数据是不一样的，导致数据包长度是不固定的，“包长”字段确定数据包中后续字节的长度，本例中的包长为0x07，是不包含包头和包长字段的后续数据的字节个数。数据采集中间件根据包中的“设备类型”字段区分设备是哪一种，如本例中根据设备类型0x02判断当前设备类型为温湿度传感器。同一设备如果数据很多，可根据功能划分为不同的包，并用不同的包类型值来区分。后续的字段是设备ID，是用来区分在一个网络中部署的多个同一种类的设备，本例中温湿度传感器的设备ID为0x01。之后是温度字段和湿度字段，都是用两个字节表示的，第一个字节表示十进制中小数点前的整数，第二个字节表示十进制中小数点后的2位整数，本例中，0x1906表示当前温度值为25.6度，0x4914表示当前湿度值为73.20RH。数据采集中间件把上述数据包进行分析后在数据库表tempHum_data插入一条新的记录，各字段赋值如下：数据ID自动加1、温度值为25.6、温度单位degC、湿度值73.2、温度单位RH、采集数据的时间近似地取网关当前时间，温湿度传感器的开/关状态为On。
步骤二：为存储智能家居设备的应用程序建立ContentProvider接口。上述第一步建立的数据库只是本地数据库，并不能让远端程序访问。本步骤的目的是提供其他应用程序访问数据库的接口，同时定义访问数据库的资源的路径-通用资源标识(URI)。
其他应用程序访问数据库中的数据并不是直接访问ContentProvider，而是通过ContentResolver来操作ContentProvider所暴露的数据。Android的ContentProvider，具有query(查询)、insert(插入)、update(更新)、delete(删除)操作(CRUD方法)，对应于具体的数据库操作。ContentResolver操作ContentProvider是通过URI实现的，通过URI参数找到该URI对应的ContentProvider,再由该ContentProvider来负责实现CRUD方法，从而实现对存储在SQLite数据库中的数据进行query、insert、update、delete操作。
Android的ContentProvider，具有query(查询)、insert(插入)、update(更新)、delete(删除)操作。对于ContentResolver来说，它是用来操作ContentProvider的，也就是说它应该操作ContentProvider的CURD四个方法，所以它也具有四个方法。
通过上面的四个方法我们可以看出来对于ContentProvider和ContentResolver的CRUD四个方法中的第一个参数是通用资源标志URI，URI是两者进行数据交换的标识。ContentResolver执行CRUD操作时会通过URI参数找到该URI对应的ContentProvider，从而使得对应的ContentProvider来负责实现CRUD方法，从而实现对存储在SQLite数据库中的数据进行query、insert、update、delete操作。URI主要包含了两部分信息：1)、需要操作的ContentProvider，2)、对ContentProvider中的什么数据进行操作。一个URI由以下3部分组成：scheme+Authority+path，其中：scheme已经由Android规定为：content://；Authority用于唯一标识这个ContentProvider，外部调用者可以根据这个标识来找到它。path用来表示我们要操作的数据，路径的构建应根据用户所访问的数据来定。如我们要访问SQLite数据表temphum_data的所有数据项，我们就可以将路径设置为/temphum_data；如果我们需要访问Sqlite数据表temphum_data的ID为35的数据项，那么我们将路径设置为/temperature_data/35。
构建一个ContentProvider只需要两步：1、定义自己的ContentProvider类，使得该类继承Android提供的ContentProvider基类。2、注册所定义的ContentProvider类，在Manifest.xml配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识的URI。
定义温湿度传感器的ContentProvider为TemProvider，首先定义TemProvider的工具类Temps,该工具类主要包含一个public static的常量，这个常量类中包含了该ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该ContentProvider的Authority为"com.zxl.homeautoprovider.temps"，同时定义Content所允许操作的7个数据列_ID，TEMPERATUREVALUE，TEMPERATUREUNIT，HUMIDITYVALUE，HUMIDITYUNIT，TIME，STATUS，定义该Content提供服务的两个URI："content://"+AUTHORITY+"/temp_data"，以及"content://"+AUTHORITY+"/temp_data/#"然后使用URIMatcher工具类为TemProvider注册URI,实现过程如下：1)、构造一个URIMatcher实例，matcher＝new URIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量表示不匹配任何路径的返回码。2)、为URIMatcher注册两个URI：1个是matcher.addURI(Temps.AUTHORITY，"temp_data"，TEMPS)，另一个为matcher.addURI(Temps.AUTHORITY,"temp_data/#",TEMP)。如果通过match(URI)方法匹配了content://com.zxl.homeautoprovider.temps/temp_data，就会返回匹配码为TEMPS，表示多个数据记录；如果通过该match(URI)方法匹配了content://com.zxl.homeautoprovider.temps/temp_data/#，那么返回的返回码为TEMP，表示某一个数据记录。
步骤三：构建智能家居设备的语义本体，描述设备类型、对象属性、数据属性，生成对应的本体描述文件(.owl文件)。1、通过对本体构建的需求分析，确定“温湿度传感器”这一本体对象覆盖的所研究领域范围为智能家居设备领域；2、列出“温湿度传感器”中涉及到的相关的重要的词语，并确定这些词语相互间的关系和属性。由于温湿度传感器的功能只有分别测试温度、湿度，温湿度传感器是智能家居设备抽象类的子类，并且温湿度传感器具有开关状态(开启/关闭)、参数(温度、湿度)的属性并且每个参数都具有自己的值和对应的单位。通过分析可知该本体对象所涉及到比较重要的词汇为home automation devices、temperature and humidity sensors、status、parameters、unit、value。3、确定描述这些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系，本例中主要有三种关系，has status(定义域为temperature and humidity sensors，值域为status)、hasunit(定义域为parameter，值域为unit)、has value(定义域为parameter，值域为value)。数据属性是类的实例包含哪些的数据，本例中的数据属性有degree C(定义域为unit，数据类型为boolean)、RH(定义域为unit，数据类型为boolean)、temperature value(定义域value，数据类型为float)、humidity value(定义域value，数据类型为float)、status(定义域为status,值域为boolean)。利用语义本体工具软件protege分别配置表示两个类的实例间关系的object property和表示类实例的属性值的data property，生成用RDF/XML语言描述的owl文件即本体文件。完整的本体描述文件放置在网关语义程序目录中，供语义转换接口组件使用。
步骤四：在智能家居语义网关中基于Android语义服务框架为每个智能家居设备开发对应的语义数据转换接口。Android语义服务框架，是指法国Inria研究中心开发的一组用于在Android移动设备上开发语义应用的软件包，包括RDFServer，RDFProvider，RDFBrowser，RDFContentResolver，其中，RDFProvider是用户需要针对具体设备开发的语义数据转换接口，允许应用程序将自己的数据暴露为RDF语义数据；RDFContentResolver是图2中的RDF解析接口，它是访问语义数据的统一接口，RDFServer是语义Web服务器，为网络上的其它计算机提供访问RDFContentResolver的能力，RDFBrowser是在网关本机上运行的语义浏览器，直接访问RDFContentResolver。
在本发明的语义网关中需为每一种智能家居设备构建一个RDF*Provider(*分别为TH，LightSensor，AirC)，RDF*Provider最终需要访问对应的Sqlite数据表。RDF*Provider实现了将智能家居设备数据暴露为RDF语义数据。RDF*Provider实例化后就会自动的注册到RDFContentResolver上，RDFContentResolver继承自Android Service，其工作过程是在后台运行的对用户而言是不可见的。
具体工作过程如下：RDFContentResolver上安装了被实例化的RDF*Provider，当RDFBrowser地址栏中输入了需要查看的智能家居设备数据的URI。温湿度传感器的第1条记录，其URI为content://com.zxl.homeautoprovider.temps/temp_data/1)，此时RDFBrowser检索到该URI并且发送给RDFContentResolver，RDFContentResolver根据该URI再查询安装在其上的URI所对应的RDFTHProvider，该provider接收到返回该条记录的语义数据的请求后，就会返回包含7组statement(由于该数据表中除了_id字段后有7列数据)的Rdf Cursor对象，RDFContentResolver进而通过Jena接口构建RDF模型，并将7组statement的<subject，predicate，object>三元组数据解析出来并添加在所构建的RDF模型对象里，最后通过写RDF，将该模型对象的数据封装成文件并且通过RDFBrowser的用户界面返回给用户。
RDFTHProvider主要是通过get(URI URI)方法实现了将TemProvider的数据暴露为语义数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。RDFContentResolver及RDFBrowser都是通过调用get()方法来获取包含多个RDFStatement对象的Rdf Curosr对象，即三元组<subject，predicate，object>对象，其中subject为当前数据id所对应的URI的字符串，predicate为数据表中字段在本体文件中的URI所对应的字符串，object为数据表中字段所对应的值。实现get()方法前，在RDFTHProvider首先要定义两个对象，它们分别是，1)、定义用于映射存储智能家居设备数据的数据表各个字段(如温湿度传感器的数据表temp_data)与temperature.owl本体文件中各个data property的URI关系的哈希表对象TEMP_PROPS，该对象的键为数据表的各个字段，值为温湿度传感器本体中所对应的data property的URI。2)、定义RDFTHProvider所对应的原始TemProvider的URI(content://com.zxl.homeautoprovider.temps/temp_data)为baseURI。该baseURI实际上就是我们需要访问的数据库表中原始无语义数据所对应的URI,也是需要我们进行语义注释的对象。
在RDFBrowser搜索温湿度传感器数据库表中的第一条记录的URI中，首先get()方法通过输入的URI对象content://com.zxl.homeautoprovider.temps/temp_data/。1)、用ContentResolver实例对象cr来调用该URI所对应的TemperatureProvider的query()方法，并且获取了包含该条记录Cursor对象。2)、Cursor对象是每一行的集合，使用moveToFirst方法来定位第一行，并通过getColumnCount()获取该条记录所有列数，共有8列(含有_id字段)。3)、根据TEMPERATURE_PROPS所含列数定义了1个含有7个元素的int型数组idx(idx[0]-idx[6]分别对应temperature_data表中的7个字段所对应的值分别为{22.6，degreeC，68.3，RH，2014-9-18 11：46：34，1，0})，判断哈希表对象TEMP_PROPS的列数与temp_data数据表中的列数是否相同，若相同就直接获取_id所在的列索引idIdx，根据判断可知idIdx为1，根据cursor.getInt(idIdx)方法获取当前记录的id值为1。4)、根据cursor.getString(idx[0])方法获取了该列名temperatureValue所对应的值为22.6。5)、并通过TEMP_PROPS.get(cursor.getColumnName(idx[0])).toString()方法获得temperatureValue键所对应的值http://localhost/temperature.owl#temperatureValue的字符串形式，该值即为本体中关于temperatureValue该dataproperty的URI所对应的字符串。6)、创建一个Statement对象stmt，a)该对象的Resource对象subject为baseURI+当前记录的id值即为content://com.zxl.homeautoprovider.temps/temp_data/1的字符串形式；b)该对象的Property对象predicate为5)中所获取的字符串“http://localhost/temperature.owl#temperatureValue”；c)该Statement对象的Object对象object为4)中所获得的值22.6。7)、通过hasNext()方法检测到还有下一列时，通过循环的方法再次构建6个Statement对象，并且6个对象的subject值都为”content://com.zxl.homeautoprovider.temps/temp_data/1”，predicate值为TEMPERATURE_PROPS其他各个键所对应的值的字符串形式，object值分别为temp_data数据表中各个字段所对应的值。至此7组RDF Statement对象都存储在了Rdf Cursor中了，从而实现了温湿度传感器第一条记录的语义注释。
步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏览器通过访问语义网关获取有语义的智能家居设备数据。在温湿度传感器语义网关设计中，假设网关IP地址为10.17.52.71，网关语义Web服务器RDFServer使用缺省端口号8080，打开Web，输入http://10.17.52.71:8080/com.zxl.homeautoprovider.temps/temp_data/1，若是输入http://10.17.52.71:8080/com.zxl.homeautoprovider.temps/temp_data/1，该URI来访问RDFserver时，RDFServer首先会接受外部请求并将外部的URI转换为内部可识别的URI content://com.zxl.homeautoprovider.temps/temp_data/1,接下来RDFServer将装换后的URI传递给RDFContentResolver，RDFContentResolver又根据该URI查找到了与之相对应的RDFContentProvider即RDFTemperatureAndHumiditySensorsProvider并调用该provider中的get()方法，从而获取包含7组RDF Statments对象的Rdf Cursor对象，进而对该Rdf Cursor通过Jena接口实现RDF解析，最终将解析后的语义数据结果以RDF文件的形式返回给了用户。
实施例2：空调。
步骤一：在Sqlite数据库HAdb中为空调设备建立Sqlite数据库表aircon_data，其中含有10个字段，分别代表了每条数据的ID、当前温度、目标温度、当前时间、目标时间、状态开、状态关、运行模式、风扇速度、定时模式。数据采集中间件获取空调通过Wifi传来的原始数据，按字段解析，生成新记录，插入aircon_data表中。
步骤二：为空调构建一个可供其他应用程序访问其数据的AirconditoningProvider接口，该接口继承了Android Content Provider。具体构建过程如下：首先定义AirConProvider的工具类AirCons，该工具类主要包含一个public static的常量，这个常量类中包含了该ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该ContentProvider的Authority为"com.zxl.homeautoprovider.aircons"，同时定义Content所允许操作的10个数据列_id，currentSetTemp，targetSetTemp，currentTime，targetTime，statusOn，statusOff，operationMode，fanSpeed，timerMode。定义两个URI："content://"+AUTHORITY+"/aircon_data"以及"content://"+AUTHORITY+"/aircon_data/#"，然后使用URIMatcher工具类为AirConProvider注册注册URI，实现过程如下：1)、构造一个URIMatcher实例matcher＝newURIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量表示不匹配任何路径的返回码。2)、为URIMatcher注册两个URI：matcher.addURI(AirCons.AUTHORITY，"aircon_data"，AIRCONS)对应多条空调数据记录和matcher.addURI(AirCons.AUTHORITY，"aircon_data/#"，AIRCON)对应单条空调数据记录。
步骤三：构建空调的本体，其过程如下。通过对本体构建的需求分析，确定“空调”这一本体对象覆盖的所研究领域范围为智能家居设备领域；列出“空调”中涉及到的相关的重要的词语，并确定这些词语相互间的关系和属性。由于空调可实现显示当前温度、设定目标温度，选择风速，选择当前的工作模式及定时等功能，且空调是智能家居设备抽象类的子类，并且空调具有开关状态(开启/关闭)。通过分析可知该本体对象所涉及到比较重要的词汇为home automation devices、air conditioning、status、parameters、unit。
确定描述这些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系，本例中主要有三种关系，has status(定义域为air conditioning，值域为status)、has unit(定义域为parameter，值域为unit)、has parameter(定义域为airconditioning，值域为parameter)。数据属性是类的实例包含哪些的数据，本例中的数据属性有current set temperature(定义域为temperature，数据类型为float)、target settemperature(定义域为temperature，数据类型为float)、fan speed(定义域airconditioning，数据类型为literal)、operate mode(定义域air conditioning，数据类型为literal)、timer mode(定义域为air conditioning,值域为literal)、status on(定义域air conditioning，数据类型为boolean)、status off(定义域air conditioning，数据类型为boolean)。利用语义本体工具软件protege分别配置表示两个类的实例间关系的object property和表示类实例的属性值的data property，生成用RDF/XML语言描述的owl文件即本体文件。完整的本体描述文件放置在网关语义程序目录中，供语义转换接口组件使用。
步骤四：构建可将空调数据暴露为供其他应用程序访问的RDF语义数据的RDFAirCProvider接口。该接口类主要是通过get(URI URI)方法实现了将AirConProvider的数据暴露为语义数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。RDFContentResolver及RDFBrowser都是通过调用get()方法来获取包含多个RDFStatement三元组<subject，predicate，object>对象的Rdf Curosr对象。其中三元组中的subject为当前数据id所对应的URI的字符串，predicate为数据表中字段在本体文件中的URI所对应的字符串，object为数据表中字段所对应的值。
实现get()方法前，在RDFAirCProvider首先要定义两个对象，它们分别是1)、定义1个用于映射存储智能家居设备数据的数据表各个字段与air_conditioning.owl本体文件中各个data property的URI关系的哈希表对象AIRCON_PROPS，该对象的键为数据表的各个字段，值为空调本体中所对应的data property的URI。2)、定义RDFAirCProvider所对应的原始AirConProvider的URI(content://com.zxl.homeautoprovider.aircons/aircon_data)为baseURI。该baseURI实际上就是我们需要访问的数据库表中原始无语义数据所对应的URI，也是需要我们进行语义注释的对象。
步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏览器通过访问语义网关获取有语义的智能家居设备数据。
实施例3：光照传感器。
步骤一：在Sqlite数据库HAdb中为空调设备建立Sqlite数据库表light_data，其中含有6个字段，分别代表了每条数据的ID、当前光照强度值、当前光照强度单位、当前时间、状态开、状态关。数据采集中间件获取光照传感器通过蓝牙无线传来的原始数据，按字段解析，生成新记录，插入light_data表中。
步骤二：为光照传感器构建一个可供其他应用程序访问其数据的LightProvider接口，该接口继承了Android Content Provider。具体构建过程如下：首先定义LightProvider的工具类Lights，该工具类主要包含一个public static的常量，这个常量类中包含了该ContentProvider所对应的URI及存储在SQLite数据库表中的数据列。其中，定义该ContentProvider的Authority为"com.zxl.homeautoprovider.lights"，同时定义Content所允许操作的6个数据列_id，lightIntensityValue，lightIntensityUnit，currentTime，statusOn，statusOff。定义两个URI："content://"+AUTHORITY+"/light_data"以及"content://"+AUTHORITY+"/light_data/#"，然后使用URIMatcher工具类为AirConProvider注册注册URI，实现过程如下：1)、构造一个URIMatcher实例matcher＝newURIMatcher(URIMatcher.NO_MATCH)，其中URIMatcher.NO_MATCH常量表示不匹配任何路径的返回码。2)、为URIMatcher注册两个URI：matcher.addURI(Lights.AUTHORITY，"light_data"，LIGHTS)对应多条光照传感器数据记录和matcher.addURI(Lights.AUTHORITY，"light_data/#"，LIGHT)对应单条光照传感器数据记录。
步骤三：构建光照传感器的本体，其过程如下。通过对本体构建的需求分析，确定“光照传感器”这一本体对象覆盖的所研究领域范围为智能家居设备领域；列出“光照传感器”中涉及到的相关的重要的词语，并确定这些词语相互间的关系和属性。由于光照传感器只有实现显示当前光照强度功能，且光照传感器是智能家居设备抽象类的子类，并且具有开关状态(开启/关闭)。通过分析可知该本体对象所涉及到比较重要的词汇为homeautomation devices、light sensor、status、parameters、light intensity、unit、value。确定描述这些资源所需要的对象属性、数据属性。对象属性描述两个类的实例间的关系，本例中主要有四种关系，has status(定义域为light sensor，值域为status)、has unit(定义域为light intensity，值域为unit)、has parameter(定义域为light sensor，值域为parameter)、has value(定义域为light intensity，值域为value)且has unit和hasvalue都是has parameter的子属性。数据属性是类的实例包含哪些的数据，本例中的数据属性有light intensity value(定义域为value，数据类型为float)、tlight intensityunit(定义域为unit，数据类型为literal)、status on(定义域light sensor，数据类型为boolean)、status off(定义域light sensor，数据类型为boolean)。利用语义本体工具软件protege分别配置表示两个类的实例间关系的object property和表示类实例的属性值的data property，生成用RDF/XML语言描述的owl文件即本体文件light_sensor.owl。完整的本体描述文件放置在网关语义程序目录中，供语义转换接口组件使用。
步骤四：构建可将光照传感器数据暴露为供其他应用程序访问的RDF语义数据的RDFLightProvider接口。该接口类主要是通过get(URI URI)方法实现了将LightProvider的数据暴露为语义数据，该方法是实现将智能家居设备的数据暴露为语义数据的最小接口。RDFContentResolver及RDFBrowser都是通过调用get()方法来获取包含多个RDFStatement三元组<subject，predicate，object>对象的Rdf Curosr对象。其中三元组中的subject为当前数据id所对应的URI的字符串，predicate为数据表中字段在本体文件中的URI所对应的字符串，object为数据表中字段所对应的值。
实现get()方法前，在RDFLightProvider首先要定义两个对象，它们分别是1)、定义1个用于映射存储智能家居设备数据的数据表各个字段与light_sensor.owl本体文件中各个data property的URI关系的哈希表对象LIGHT_PROPS，该对象的键为数据表的各个字段，值为光照传感器本体中所对应的data property的URI。2)、定义RDFLightProvider所对应的原始LightProvider的URI(content://com.zxl.homeautoprovider.lights/light_data)为baseURI。该baseURI实际上就是我们需要访问的数据库表中原始无语义数据所对应的URI，也是需要我们进行语义注释的对象。
步骤五：启动智能家居语义网关的语义Web服务器，通过浏览器来访问语义网关获取智能家居设备的有语义数据。在智能家居语义网关上安装语义Web服务器RDFServer，该服务器允许网关将语义数据在Web上进行发布，RDFServer缺省采用8080端口。本地或远端的浏览器通过访问语义网关获取有语义的光照传感器数据。
Claims (4)
1.一种智能家居语义网关的设计方法，基于Android平台，其特征在于，具体步骤如下：
步骤1：在Android平台上创建保存智能家居设备数据的Sqlite数据库Hadb，根据每一种设备的上传数据建立该设备对应的数据表，用来保存设备周期性发来的数据，同时构建一个数据采集中间件，用来接收数据、解析数据并存入到Android平台的数据库中；
步骤2：为访问智能家居设备的应用程序建立ContentProvider接口；定义访问数据库资源的路径，即通用资源标识URI，先定义ContentProvider类，使该类继承Android提供的ContentProvider基类；再注册定义的ContentProvider类，在Manifest.xml配置文件中注册用户定义的ContentProvider，并为该ContentProvider绑定一个唯一标识的URI；
步骤3：构建智能家居设备的语义本体，描述设备类型、对象属性、数据属性，生成对应的本体描述文件，即.owl文件，OWL文件是采用Web本体语言刻画语义本体的文件；智能家居设备的本体描述文件刻画智能家居设备中涉及到的词汇以及词汇之间的关系；
步骤4：为每个智能家居设备开发对应的语义数据转换接口，在Android语义服务框架下，为每一种智能家居设备构建一个RDF Provider，RDF Provider需要访问对应的Sqlite数据表，实现将智能家居设备数据暴露为RDF语义数据，并自动地注册到RDFContentResolver上；
步骤5：启动智能家居语义网关的语义服务器，通过浏览器来访问语义网关获取智能家居设备的语义数据。
2.根据权利要求1所述一种智能家居语义网关的设计方法，其特征在于，Android平台为Android平板平台或者Android智能手机平台。
3.根据权利要求2所述一种智能家居语义网关的设计方法，其特征在于，所述RDFProvider为RDF TH Provider、RDF LightSensor Provider或RDF AirC Provider。
4.根据权利要求3所述一种智能家居语义网关的设计方法，其特征在于，所述步骤5包括在智能家居语义网关上安装语义Web服务器RDF Server。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410619121.4A CN104410568B (zh) | 2014-11-06 | 2014-11-06 | 一种智能家居语义网关的设计方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410619121.4A CN104410568B (zh) | 2014-11-06 | 2014-11-06 | 一种智能家居语义网关的设计方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104410568A CN104410568A (zh) | 2015-03-11 |
| CN104410568B true CN104410568B (zh) | 2017-10-03 |
Family
ID=52648166
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410619121.4A Expired - Fee Related CN104410568B (zh) | 2014-11-06 | 2014-11-06 | 一种智能家居语义网关的设计方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104410568B (zh) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104866538A (zh) * | 2015-04-30 | 2015-08-26 | 北京海尔广科数字技术有限公司 | 一种动态更新语义告警库的方法、网络及系统 |
| CN105450654B (zh) * | 2015-12-08 | 2019-09-27 | 深圳市讯方技术股份有限公司 | 基于中间件技术的智能家居开发平台及其业务开发方法 |
| CN106354534A (zh) * | 2016-08-30 | 2017-01-25 | 歌尔科技有限公司 | Android系统下客户端对服务器中应用程序的控制方法 |
| TWI658712B (zh) * | 2017-09-13 | 2019-05-01 | 財團法人資訊工業策進會 | 閘道器與在閘道器上判斷欲聯網機器的方法 |
| CN108366003B (zh) * | 2017-12-26 | 2021-06-11 | 海尔优家智能科技（北京）有限公司 | 家居服务框架创建方法、调用方法、装置、服务器及介质 |
| CN109361579B (zh) * | 2017-12-29 | 2021-11-23 | 深圳Tcl新技术有限公司 | 一种智能设备控制方法、系统及存储介质 |
| CN110390020A (zh) * | 2018-04-19 | 2019-10-29 | 株式会社日立制作所 | 语义网关的建模方法和语义网关 |
| CN111913476B (zh) * | 2020-08-10 | 2022-09-16 | 北京航天发射技术研究所 | 一种无人艇航行控制软件架构方法及装置 |
| CN113706668B (zh) * | 2021-07-27 | 2024-02-23 | 杭州玖欣物联科技有限公司 | 一种根据网关数据实现玻璃运行三维动画的方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101540829A (zh) * | 2009-04-23 | 2009-09-23 | 中山大学 | 一种基于sdf数字家庭中间件的智能家居控制系统 |
| CN103312573B (zh) * | 2013-06-14 | 2016-12-28 | 西安交通大学 | 一种家庭网络系统设备发现与识别方法 |
| CN103592925A (zh) * | 2013-11-25 | 2014-02-19 | 吉林大学 | 一种基于语义融合的智能家居系统 |
-
2014
- 2014-11-06 CN CN201410619121.4A patent/CN104410568B/zh not_active Expired - Fee Related
Non-Patent Citations (2)
| Title |
|---|
| 一种基于语义融合的智能家居系统的研究与实现;李程贵;《中国优秀硕士论文全文数据库 信息科技辑》;20120915;正文第1-54页 * |
| 基于本体的制造企业知识集成技术的研究;倪益华;《中国博士学位论文全文数据库 工程科学II辑》;20051215;正文第63-80页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104410568A (zh) | 2015-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN104410568B (zh) | 一种智能家居语义网关的设计方法 | |
| CN113196192B (zh) | 用于将工业过程装备的描述转换成数据信息模型的网关和方法 | |
| CN108604236B (zh) | 语义物联网的restful操作 | |
| EP3520360A1 (en) | Access control policy synchronization for service layer | |
| Bolchini et al. | Context Modeling and Context Awareness: steps forward in the Context− ADDICT project | |
| CN103838837B (zh) | 基于语义模板的遥感元数据集成方法 | |
| CN107515887A (zh) | 一种适用于多种大数据管理系统的交互式查询方法 | |
| ES2904887T3 (es) | Sistema de gestión de edificios con base de conocimientos | |
| CN112256927B (zh) | 基于属性图的知识图谱数据处理方法和装置 | |
| CN103577198A (zh) | 一种面向用户的物联网服务平台及远程控制方法 | |
| KR20210089772A (ko) | 자동화 목적들을 위한 데이터 모델을 타겟 온톨로지로 변환하기 위한 방법 | |
| Steindl et al. | Ontology-based opc ua data access via custom property functions | |
| CN112597129A (zh) | 基于结构化数据库的opc ua信息模型自动构建方法 | |
| Antunes et al. | Context storage for m2m scenarios | |
| Kuller et al. | Conceptual design of a digital twin based on semantic web technologies in the smart home context | |
| Lv et al. | Research on unified architecture of IoT system | |
| Seok et al. | Implementing A Semantic-based loT Mashup Service | |
| Pelesić | Semantic interoperability layer for oBIX | |
| Tsai et al. | Ontology patterns for service‐oriented software development | |
| Ribeiro | Data modeling for the Internet of Things | |
| Fortuna et al. | Towards building a global oracle: a physical mashup using artificial intelligence technology | |
| Vadivel et al. | Semantic Technologies for IoT | |
| Adebayo | Specification of a smart meter/actuator description mechanism & development of a mobile application | |
| Hsiao et al. | Translation of extended entity-relationship database model into object-oriented database model | |
| Sergeevitch | Information systems metamodels developing for providing structural and semantic interoperability |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20171003 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |