物联网协同框架IoTivity简介(部分).doc

. . . . .

目录
一、物联网操作系统的整体架构5
1.物联网操作系统整体架构概述5
a)物联网操作系统核概述5
b)外围功能组件概述6
c)物联网协同框架概述6
d)公共智能引擎概述8
e)集成开发环境概述8
f)物联网领域应用概述8
g)物联网操作系统整体架构总结9
h)物联网操作系统在不同场景的应用举例10
2.物联网操作系统架构详解10
a)核的主要组成部件10
i.物联网设备硬件11
ii.硬件抽象层〔HAL〕11
iii.设备管理框架与设备驱动11
iv.任务管理11
v.存管理11
vi.中断管理12
vii.核同步12
viii.安全与权限12
ix.核统计12
x.应用管理12
xi.核API12
b)外围功能组件的主要组成部件13
i.在线更新13
ii.C运行库13
iii.安全传输协议13
iv.TCP/IP协议栈13
v.Java虚拟机13
vi.文件系统13
vii.图形用户界面13
c)物联网协同框架主要功能描述14
d)公共智能引擎主要组成部件14
e)集成开发环境主要功能描述14
二、核：专为物联网而生14
2.物联网操作系统核概述14
a)物联网操作系统核的特点14
b)任务管理子系统14
i.任务管理子系统概述14
ii.任务的状态与切换15
iii.任务调度算法17
c)存管理子系统18
i.存管理概述18
ii.物理存管理算法-空闲链表法18
iii.物理存管理算法-固定存块链表法20
d)设备管理子系统20
e)核辅助子系统20
i.安全与权限管理20
ii.核统计20
iii.硬件抽象层〔HAL〕20
3.可伸缩机制：核能大能小20
a)基于宏定义的编译配置20
b)基于列表的模块加载20
c)可加载外部模块20
4.任务管理：兼顾效率与扩展性20
a)线程调度20
b)核同步21
c)核休眠：能节电就节电21
5.存管理子系统21
a)固定尺寸存块链表：确保存分配时间21
b)空闲存块链表：充分提升存使用效率21
c)基于硬件MMU的存保护21
d)存对齐21
e)存清零21
f)基于硬件MMU的存空间隔离21
6.设备管理子系统22
a)中断管理22
i.中断管理概述22
ii.毫秒级时钟中断22
iii.中断嵌套技术23
iv.可控锁中断技术23
v.中断扼杀机制23
b)设备命名与标识24
c)总线管理24
d)设备驱动程序24
7.核辅助子系统24
a)核的安全与可靠性24
i.核对象签名24
ii.看门狗技术24
iii.限制队列机制24
iv.基于染色的堆栈异常检测24
v.隔离数据区机制24
vi.加密与验证24
b)核效率保障机制24
i.系统时钟动态调整24
ii.Direct Ethernet技术24
c)核统计25
i.CPU占用率统计25
ii.存分配统计25
iii.中断统计25
d)硬件抽象层25
i.硬件抽象层主要功能25
ii.非对齐访问25
iii.CPU大头与小头25
三、物联网操作系统的外围功能组件25
1.外围功能组件概述25
2.JAVA虚拟机：实现软硬件别离26
3.在线更新机制27
4.用户界面〔shell〕27
5.数据加密与安全套接字〔SSL〕27
6.简化的TCP/IP协议栈27
7.文件系统27
8.图形用户界面27
四、物联网操作系统协同框架27
1.物联网协同框架综述27
a)低功耗连接协议29
i.CoAP协议29
b)标准化的操作模式34
c)设备全局标识34
d)Restful资源标识34
e)设备配置与激活34
f)设备发现34
g)设备认证与权限管理34
h)设备交互35
2.IoTivity框架36
a)IoTivity协同框架概述36
b)IoTivity协同框架主要功能36
c)IoTivity协同框架整体架构36
i.IoTivity的核心服务层38
ii.IoTivity的附加服务层39
d)IoTivity主要技术实现39
i.IoTivity的软件架构40
ii.IoTivity的资源标识与标准操作模式40
iii.IoTivity设备的初始化40
iv.IoTivity设备注册41
v.IoTivity设备的发现机制42
vi.IoTivity设备信息获取45
vii.IoTivity设备配置修改47
viii.IoTivity场景管理器47
ix.IoTivity软件定义传感器49
x.IoTivity服务目录49
xi.IoTivity多协议通信网关49
e)IoTivity开发实例49
f)IoTivity优点和不足分析49
3.Google Weave框架49
g)Weave背景与定位49
h)Weave的主要特点50
i)Weave的整体架构50
i.LibWeave和uWweave51
ii.智能手机客户端52
iii.Weave Cloud52
iv.Weave API53
j)Weave的主要技术实现54
i.标准的命令和状态Schema55
ii.用户权限管理58
iii.针对低功耗蓝牙的深度优化58
iv.针对资源受限系统的专门设计59
k)Weave开发举例60
l)Weave优点和不足分析60
4.不同协同框架的比照分析61
五、公共智能引擎61
1.公共智能引擎概述61
2.公共机器学习引擎61
3.DSL语言与处理引擎62
4.语音与语义识别引擎62
六、物联网操作系统开发环境与运行支撑体系62
1.开发环境62
2.运行支持机制62
a)物联网操作系统辅助平台62
b)开发社区支持62
c)物联网领域应用62

1. IoTivity框架
a) IoTivity协同框架概述
我们知道，由于缺乏标准，不同的物联网设备和系统之间直接交互非常困难，这样就无法实现物联网的“协同〞特性。比如有的设备支持低功耗蓝牙(BLE)，有的设备支持WiFi，有的物联网设备那么支持Zigbee，这些设备之间因为缺乏统一的通信标准，相互之间无法通信。
为了解决不同物联网设备之间的互通问题，由高通，Microsoft，Intel等等业界顶级的IT公司组成了一个叫做开放互联联盟〔Open Interconnect Consortium，OIC〕的组织(后续简称为OIC)，专门制定不同物联网设备之间的互联通信标准。目前来说，参与OIC的公司，已经超过了100多家。OIC定义了一套完整的设备之间的通信标准，只要物联网设备遵循这些标准，相互之间就可以相互通信，并能够相互协同工作。
OIC是由很多不同职责的小组组成的，其中核心小组〔Core Group〕定义了开放互联标准的最核心机制，包括根本的通信协议，安全保证机制，设备命名和资源发布机制，等等。另外还有很多专注于“垂直〞应用的小组，比如智慧家庭，工业应用，智慧医疗等。这些垂直应用小组基于核心小组定义的根本机制，来进一步细化和定义垂直领域相关的通信标准。所有这些不同的小组定义的标准，组成了OIC的开放互联标准体系。同时，OIC还设计了认证机制，通过OIC认证的设备，可以确保能够跟其它功能相关〔比如，属于同一垂直领域〕的设备进展直接交互，而不管这些设备是不是由同一个厂商开发的。
在当前代码为王的时代，只有标准是远远不够的，还必须有与之配套的实现代码，以供物联网设备商直接参考。于是在Linux基金会的支持下，OIC专门成立了一个叫做“IoTivity〞的项目，用于实现OIC制定的物联网设备互联标准。从IoTivity的名字就可以看出来，这个项目就是瞄准物联网〔IoT〕的。
本质上，IoTivity是一个开源项目的名字，这个项目的目的是为了实现OIC定义的开放互联标准。这个项目最终实现的软件，也被成为IoTivity框架，在本书中叫做“IoTivity协同框架〞，强调物联网的“协同〞特性。
b) IoTivity协同框架主要功能

c) IoTivity协同框架整体架构
IoTivity是一个典型的物联网协同框架，其软件组成，也符合物联网协同框架的组成三要素-人侧软件，物侧软件和云侧软件。以下图示意了IoTivity的软件组成：

其中IoTivity Client就是运行在用户智能手机，电脑，PAD等设备上的人侧软件。而IoTivity Device那么是运行在物联网设备上的物侧软件，也是IoTivity项目重点开发和实现的软件，在接下来的局部中，我们重点介绍IoTivity Device，与物侧软件。IoTivity Cloud是最新版本的IoTivity推出的一项服务，它实现了一个简单的物联网后台系统。
需要注意的是，IoTivity Client可以通过本地局域网，直接控制IoTivity设备，无需经过IoTivity后台。前提是IoTivity Client和IoTivity Device能够位于同一个本地局域网上，能够通过WiFi，蓝牙或者Ethernet等网络技术直接通信。这与物联网协同框架中定义的人侧软件和物侧软件交互机制一样。
在IoTivity的实现中，Client通过CoAP协议与物联网设备交互。CoAP协议是基于IP/UDP协议的一种低功耗通信协议，该协议通过利用IP的组播功能，实现了设备的发现机制。具体来说，就是运行IoTivity Client的设备，比如手机，电脑等，在本地局域网上发送设备发现请求〔Device Discovery〕，该请一个组播IP报文，会被所有运行IoTivity Device的物联网设备接收到。在请求报文中，Client会指定待发现的设备类型，比如智慧灯泡，智慧门锁，等等。接收到发现请求的物联网设备，首先匹配自己的设备类型与请求报文中的设备类型，如果一致，那么单独给Client一个回应。如果不匹配，那么直接丢弃该发现报文，不做任何回应。通过这种机制，IoTivity Client就会把局域网中的所有物联网设备“收集上来〞，并呈现给用户，从而完成管理和控制功能。这个过程中，还涉与到认证，权限管理，加密等等细节，在后面的局部中，我们会详细介绍。
相对运行在物联网设备上的IoTivity Device软件，IoTivity Client和IoTivity Cloud的比重都比拟少，属于“附属功能〞，因此在本书中不做详细介绍。更方便的是，IoTivity提供了这两类软件的根本组态〔各类可直接的代码库〕，在具体物联网软件开发中，直接引用即可，定制的工作量并不大。下面详细介绍运行在物联网设备中的IoTivity Device软件。
以下图示意了IoTivity Device的整体技术框架：

整个IoTivity的功能大致分为三层：最底层是核心服务层〔Base Layer〕，中间一层是IoTivity服务层，最上层是具体的物联网应用，比如智慧家庭，智慧医疗，等等。
同时为了处理上的方便，IoTivity把目标设备分为了两类，一类是功能和资源丰富的智能设备〔称为Rich device，后续翻译为智能设备〕，比如手机，家庭网关，智慧电视等。这类设备具备强大的CPU处理能力，具备几百兆甚至数G的存，具备丰富的通信能力。另外一类叫做小型设备〔Lite Device，后续翻译为资源受限设备〕，这类设备的计算能力和通信能力往往很局限，比如一些基于嵌入式控制器的嵌入式系统等。在这两类设备中，智能设备运行全部的IoTivity协议栈，而功能受限设备，那么只运行IoTivity的核心服务层。因为IoTivity的服务层需要相对强大的处理能力和计算资源，因此一般情况下无法在资源受限系统中运行。
核心服务层是IoTivity的核心，所有其它的层次，都是基于根本服务层进展构筑的。核心服务层包括设备发现，设备消息交互，通信安全，以与一个抽象的连接层。核心服务以C语言实现，通过C语言API向上层提供接口，供上层功能调用。核心服务层保存了最根本的功能和服务，因此对硬件设备的要求不高，可以运行在资源受限设备上。
IoTivity服务层那么实现了常见的补充功能，包括物联网设备管理，物联网设备的数据管理，低功耗支持，资源封装，资源容器等功能。该层次是基于IoTivity的核心功能层实现的。与核心功能层不同，IoTivity服务层是以C++语言实现，其API也是基于C++语言的。这个功能层对硬件计算能力和通信能力有较高的要求，大局部情况下都运行在智能设备上，很少〔或没有〕运行在资源受限设备中。
最上层那么是具体的应用层，比如智慧家庭，远程医疗，智慧城市等等。这些应用程序通过调用IoTivity的API接口(包括IoTivity的服务层API接口，以与IoTivity的核心层API接口)，来实现特定的垂直功能。这局部容是于具体的应用领域强相关的。
需要强调的是，应用层APP并不是只能调用IoTivity服务层的API接口，也可以调用IoTivity的核心服务API，需要根据实际需要具体实现。
下面重点介绍IoTivity的核心服务层和IoTivity服务层，应用层因为与具体的垂直领域有关，在此不做重点说明。
i. IoTivity的核心服务层
以下图示意了IoTivity核心服务层的主要构成：

对三个大类，每个大类中的每个模块进展具体说明。

IoTivity的设计目标之一，就是支持多种现有的通信技术或协议，比如低功耗蓝牙，6LowPan，WiFi(IPv4和IPv6)，以与支持远程连接的XMPP等协议。为了屏蔽这些不同协议或技术的细节，使得上层软件能够一致的访问不同的底层通信协议，IoTivity专门定义了一个通信抽象层〔Connectivity Abstraction Layer，CAL〕。
所有的底层通信技术的实现细节，都隐藏在通信抽象层之下。通信抽象层提供了一个公共的平台层，为构筑在CAL之上的软件，比如C Stack，安全机制等提供了统一的接口。同时，CAL还针对不同的底层通信技术，也向上提供了特定通信技术有关的功能接口，供上层软件按需调用。
对资源服务器来说，CAL提供了组播报文的接收功能，以便资源服务器能够接收到来自客户端的资源发现请求。同时，CAL也提供了针对资源受限设备的“组播禁止〞功能，以便于这些资源受限设备能够按需禁止组播，以节约能耗。
ii. IoTivity的附加服务层
附加服务层〔在IoTivity框架中叫做Service Layer，为了与核心服务区别，翻译为“辅助服务层〞〕是IoTivity基于根底服务层开发的支撑物联网特定场景应用的公共服务，这些公共服务以组件化形式存在，每个服务服务都提供特定的API(C++语言)，供开发者调用，来实现某个特定的功能。这些辅助服务都有比拟广泛的普适性，否那么IoTivity也不会开发。
IoTivity附加服务层依赖于IoTivity的核心服务层，需要调用核心服务层提供的API(C语言API)，来完成特定的操作。IoTivity附加服务层与核心服务层的关系，类似于物联网操作系统核与外围功能组件之间的关系。同时，IoTivity的附加服务层的功能组件也不是固定的，而是随着IoTivity的开展，以与应用场景的变化，而不断变化和增加。
以下图示意了IoTivity附加服务层的主要构成：

对五个大类，以与每个大类中的每个模块，进展具体说明。
d) IoTivity主要技术实现
在对IoTivity的整体架构和主要功能有了初步的了解之后，我们再深入IoTivity部，看看IoTivity主要模块〔或功能〕的技术实现。本局部容主要是面向IoTivity的开发者编写的，通过对IoTivity的部实现有清晰的了解，可以帮助开发者更好的实现应用程序。
i. IoTivity的软件架构
上面介绍了IoTivity的功能架构，下面简单介绍其软件架构。以下图示意了IoTivity的软件分层结构：

在软件实现上，IoTivity基于清晰的层次结构。图中最上面和最下面两层，分别是物联网应用程序和网络硬件，严格来说不属于IoTivity的畴。当前的IoTivity实现是基于CoAP协议作为其根底通信协议，我们知道，CoAP协议基于UDP/IP协议实现。
IoTivity的整个软件体系又进一步分为核心功能层和附加服务层，其中核心服务层就在上图中IoTivity Base这个软件层次中实现，这包括设备发现，远程访问等等根底能力。核心服务层的API是基于C语言实现的，可以很方便的移植到资源受限的嵌入式系统中。
在核心服务层之上，就是IoTivity的附加服务层。该层次通过C++语言实现其API，并实现了诸如easy setup，Group Manager等根底服务。
如果IoTivity是面向资源受限的硬件设备，那么只需要移植核心服务层即可。如果是面向资源不受限的智能硬件平台，同时又需要支持完整的IoTivity附加服务，那么需要移植基于C++的附加服务层。
ii. IoTivity的资源标识与标准操作模式

iii. IoTivity设备的初始化
分为两类：一类是针对特定应用场景的批量初始化，比如智慧路灯，智慧商场中的各类传感器，等等。这类设备在设备投放使用之前，就已经完成初始化，比如设备的蓝牙PIN码，WiFi密码与SSID，服务器端的IP地址或者域名，以与各类参数。这类设备的初始化，一般是由系统集成商来定制完成的。这类设备的初始化过程比拟简单直观，只需要在设备的软件中预置相关参数即可，本文不做深入描述。
另外一类设备是面向消费者的设备，比如智慧灯泡，智慧家电，等等。这类设备是面向海量用户市场，每个用户的设置和运行环境都不一样，比如用户A的WiFi密码，与用户B的WiFi密码就不一样，这样就无法做到出厂时的初始化，必须在用户购置之后，针对其特定的应用环境完成初始化。为了完成这项初始化的工作，IoTivity提供了一些可选的服务和机制，本文中进展详细描述。
iv. IoTivity设备注册
IoTivity协议栈提供了公共的设备资源管理能力，任何基于IoTivity开发，并向外提供物联网服务的设备，比如智慧灯泡，智慧空调等，都需要把自己提供的功能注册到IoTivity的核心协议栈中。只有注册到IoTivity的设备资源，才能被IoTivity Client发现。
需要注意的是，这里的注册，并不是物联网设备向物联网后台等云端软件的注册，而是基于IoTivity的物联网应用程序，向IoTivity核心代码库进展注册。这些软件都运行在同一台物联网设备中。因此严格来说，这里的注册，应该是“不同软件模块之间的信息交互〞。以下图示意了这个逻辑：

注册的工作，由物联网设备应用程序完成。设备应用程序调用IoTivity提供的API注册自己，以下图示意了这个过程：

在注册的时候，物联网应用程序〔ISV Server App〕调用C++ SDK提供的registerResource函数〔该函数属于一个叫做platform的对象〕，该函数进一步调用C SDK提供的API，最终在IoTivity的核心中完成注册。如果这个过程一切正常，那么最终会返回给应用程序success，任何一个步骤失败，都会返回failure。
物联网应用程序在注册资源的时候，需要指定资源的URI，资源的类型〔比如智慧灯泡，智慧门锁等〕，例如下面的代码示例：
OCResourceHandle resourceHandle;
std::string resourceURI = "/light/1";
std::string resourceTypeName = "alpha.light";
std::string resourceInterface = DEFAULT_INTERFACE;
uint8_t resourceProperty = OC_DISCOVERABLE | OC_OBSERVABLE;

OCStackResult result = platform.registerResource(resourceHandle, resourceURI,
resourceTypeName, resourceInterface, &entityHandler, resourceProperty);
if (OC_STACK_OK == result)
{
//Successfull
}

URI(代码中的resourceURI)用于IoTivity Client访问资源的唯一〔或标识〕。需要注意的是，物联网应用程序在调用registerResource的时候，指定的是URI的一局部。IoTivity核心服务会把物联网设备的IP地址与端口号附加在前面，形成一个完整的URI。在这个实例中，如果物联网设备的IP地址是：192.168.0.11，那么IoTivity形成的完整的URI是：coap://192.168.0.11:5638/light/1.
注册完成之后，物联网设备对应的服务资源就呈现在IoTivity整体框架中了，这时候IoTivity Client就可以通过资源发现机制，发现相应的物联网资源，并进展调用或控制。
v. IoTivity设备的发现机制
IoTivity Client〔物联网协同框架的人侧软件〕是通过发现机制〔Discovery〕来发现IoTivity服务器，并建立关联关系，从而完成管理和控制。一般情况下，IoTivity Client和所有提供服务的IoTivity Server在同一个局域网，比如都位于家庭WiFi网络中。Client在整个局域网上发送Discovery组播，在组播报文中携带了希望发现的资源类型，比如智慧灯泡，智慧门锁等。
运行IoTivity协议栈的所有物联网设备都会收到这个组播消息。但是只有设备类型符合的物联网设备，才会向Client发送一个回复。在这个回复中，包含了资源URI等信息，Client可以通过URI直接访问到该资源。以下图示意了这个过程：

在该实例中，Client通过IP组播(multicase)，发送一个获取资源类型是“智慧灯泡〞〔oc/core?rt=light〕的发现请求。组播报文会被所有运行IoTivity协议栈的设备收到，在这个图中，共有三个物联网设备，其中两个是智慧灯泡，一个是风扇。只有智慧灯泡的资源类型匹配Client发出的发现请求，因此这两个智慧灯泡〔IP地址分别是192.168.1.11和192.168.1.12〕分别向Client发送一个回复消息。
Client收到这两个回复消息之后，就知道在这个网络上，有两个智慧灯泡，于是会存储这两个智慧灯泡的相关信息，并呈现在用户界面中。用户就可以对这两个智慧灯泡进展操作了。
上面描述的是资源发现的业务逻辑，在实际操作上，IoTivity Client必须调用IoTivity SDK提供的API，来启动发现过程。以下图示意了发现过程中的函数调用关系：

Client APP首先调用SDK提供的findResource函数，启动资源发现过程。在调用这个函数时，需要指定待发现的资源类型，以与一个回掉函数。因为资源发现是异步过程，也就是说Client APP无法事先知道什么时候会返回结果，因此只能向IoTivity注册一个回掉函数，在IoTivity收到物联网设备返回的应答消息后，会调用这个回掉函数，通知Client APP，已经发现了想要的资源。
SDK的findResource函数进一步调用IoTivity Client封装层提供的findResource函数，封装层再调用IoTivity核心服务层提供的OCDoResource函数，这个函数构造一个CoAP报文，并把该CoAP报文封装在一个组播IP报文中，发送到网络上。
网络上的物联网设备收到发现请求消息之后，会匹配资源类型，如果类型匹配，那么以单播〔unicast〕形式，向IoTivity Client APP回复一个发现应答。这个应到被IoTivity核心服务层收到，核心服务层调用SDK注册的回掉函数，最终调用到Client APP在调用findResource时注册的回掉函数。这样Client APP就可以收到资源发现的应答，从而记录资源信息，并向用户呈现，接收用户的控制。
让我们把资源发现的目光再深入到网络层，看看IoTivity Client和IoTivity资源服务器之间的报文交互。运行在Client上的IoTivity核心服务层会根据findResource函数指定的参数，构造一个CoAP协议数据报文，并以组播方式发送到网络上。下面的表格示意了构造的CoAP报文：

Field
Value
Note(s)
Address
224.0.1.187:5683
组播IP地址与端口号
Header
NON,
GET,
MID=0x7d40
资源发现请不需要回复确认的
URI-Path
oc
"/oc/core?rt=alpha.light"
URI-Path
core
URI-Query
rt=alpha.light
Accept
application/json
接收响应的容格式

Client通过组播方式，把Discovery报文发送到网络上。224.0.1.187是一个组播地址，所有运行IoTivity的物联网设备都会监听这个地址，可以接收到任何被发送到这个组播IP地址的报文。5683是对应的UDP端口号。CoAP的报文类型是NON，即不需要接收端确认。因为这个报文会被多个物联网设备接收到，因此无法采用确认机制。CoAP请求的方法是GET即获取地址。消息ID(MID)是0x7d40。
最关键的信息，是CoAP报文的选项〔Option〕。这个资源发现报文包含了两个URI-Path选项，一个待发现的资源类型，以与一个可以接收的容解析格式〔JSON〕。这里也可以看出，通过携带多个URI-Path选项，就可以形成一种层次化的目录格式。比如在这个例子中，两个URI-Path结合起来，就形成了〞/oc/core〞这样一个层次化路径。CoAP报文中携带的URI路径信息，与目标主机的IP地址或域名结合起来，就形成了一个完整的URI。比如224.0.1.187:5683/oc/core.
而待发现的资源类型选项〔URI-Query〕，那么指定了感兴趣的物联网设备类型。在这个例子中，是智慧灯泡〔alpha.light〕。可以通过修改资源类型，来发现其它物联网设备，比如传感器〔sensor〕，门锁〔lock〕，等等。
最后一个选项Accept，指明了响应报文中的容格式，即如果被发现设备响应这个发现请求，应该以什么样的数据格式来描述自己。在这里，Client希望收到以JSON格式描述自身属性的发现响应。
网络上所有运行IoTivity的物联网设备，都会接收到这个资源发现请求〔网络异常情况，比如丢包等，不做考虑〕。物联网设备会解析CoAP资源发现请求，用自己的资源类型去匹配请求的资源类型〔即alpha.light〕。如果不匹配，那么忽略该响应，如果匹配，那么回复一个发现应答消息。下表示意了来自IP地址是192.168.1.1的响应：

Field
Value
Explanation
Address
192.168.1.1:5683
Client Address
Header
ACK
CONTENT
MID=0x7d40
Success w/content
Content
Format
application/json

Payload
[ { "href" : "/light/1", "rt":["alpha.light"], "if":["oc.mi.def"], "obs":1} ]

与资源发现请求不同，发现响应报文是单播报文，目标设备直接把响应发送给IoTivity Client。在响应报文中，CoAP报文类型是ACK，响应报文的消息ID(MID)与资源发现报文一样，都是0x7d40，标识了同一个会话。而CoAP的Content Format选项，与资源发现请求的Accept选项相对应，都是JSON格式。在响应报文的负载中，包含了设备的具体信息，比如设备的URI是“/light/1〞，类型是light，等等。需要注意的是，响应报文的URI，与设备的IP地址组合起来，就是设备的完整URI，在这个例子中，是192.168.1.1:5683/light/1，IoTivity Client可以通过访问这个URI，来操作物联网设备。
vi. IoTivity设备信息获取
IoTivity通过发现过程，把网络上的物联网设备收集起来。这时候用户就可以通过IoTivity Client的GUI，看到网络上的所有物联网设备与设备类型了。如果用户选定某一个物联网设备，比如智慧灯泡，希望进一步查看选定物联网设备的信息〔比如智慧灯泡当前的亮度与颜色信息〕，那么会触发IoTivity设备信息获取流程。以下图示意了这个过程：

（1） IoTivity Client调用SDK提供的resource.get函数，试图获取目标设备的状态信息。在调用该函数的时候，需要指定一个回掉函数。在物联网设备的状态信息返回之后，IoTivity会调用这个回掉函数，通知IoTivity Client结果；
（2） SDK的get函数会进一步调用部封装层提供的get函数；
（3） 部封装层的get函数会调用IoTivity的C API函数OCDoResource，该函数会根据传递过来的参数，比如目标设备的URI，来构造一个CoAP报文，然后发送到网络上。这个CoAP报文的方法是GET，里面携带了目标设备的URI；
（4） 这个CoAP报文跨越网络，被发送到目标物联网设备；
（5） 目标物联网设备的IoTivity核心服务代码分析CoAP报文，根据URI来调用对应的处理函数。针对不同的CoAP方法，比如GET，PUT，POST，等等，IoTivity核心服务层都有对应的处理函数。在这里会调用GET处理函数；
（6） IoTivity的GET处理函数会进一步调用封装层提供的OCResource函数，该函数会进一步通过C++ SDK的框架代码，调用到最终物联网服务的处理函数；
（7） 物联网服务处理函数根据请求类型，返回处理结果。这个处理结果一直返回到物联网设备的IoTivity核心服务层〔对应图中的8/9/10三步〕；
（8） 物联网设备的IoTivity核心服务层构造一个CoAP协议报文，该报文的类型是ACK，里面携带了具体的容。物联网设备把这个CoAP报文发送到网络上，最终到达IoTivity Client；
（9） 经过几个回掉，IoTivity Client端代码最终调用到客户指定的回掉函数，把设备返回结果提交给用户代码。用户代码在回掉函数中，会把获取到的信息〔比如智慧灯泡的亮度〕显示给最终用户。

下面我们在深入到上述过程中构造的两个CoAP报文，看看它们的构成，会对这个过程有更进一步的理解。下表示意了由IoTivity Client发出的CoAP报文：
Field
Value
Note(s)
Address
192.168.1.11:5683
Unicast packet
Header
CON, GET, MID=0x7d42
Confirmation is requested
URI-Path
light
"/light/1"
URI-Path
1
Accept
application/json

这个CoAP报文的目标地址，是一个单播IP地址，直接发到一个具体的物联网设备。这与设备发现过程不同，因为在信息获取过程中，用户已经指定了一个具体的物联网设备，所以IoTivity Client会直接把GET请求发送到该设备。
这个CoAP的类型是CON，即需要接收端确认。方法是GET，消息ID是0x7d42。该报文过两个URI-Path选项，指定了目标物联网设备上的目标资源。同时该CoAP请求指明了期望的响应数据格式为JSON。
下表示意了由物联网设备返回给IoTivity Client的CoAP报文：
Field
Value
Explanation
Address
192.168.1.1:5683
Client Address
Header
ACK
CONTENT,
MID=0x7d42
Success w/Content
ContentType
application/json

Payload
{
"power" : 0,
"level" : 10
}

返回的CoAP报文含义非常明显了，目标地址是IoTivity Client设备的IP地址，CoAP报文头中的各个资源，分别与CoAP请求对应。返回的容格式为JSON，这与请求报文中指定的格式一致。在响应报文的负载〔payload〕中，以JSON格式记录了智慧灯泡的电量和发光度〔power和level〕。
vii. IoTivity设备配置修改

viii. IoTivity场景管理器
“场景〔scene〕〞是IoTivity引入的一个概念，用于描述某个特定的功能组合，这些功能组合表达了某些特殊的应用场景。比如，在智能家居解决方案中，“看电视〞和“家庭影院〞分别是两个不同的场景，这两个场景分别对应不同家庭设备的状态组合。比如在“看电视〞场景中，灯要打开，电视要打开，但是扬声器要关闭。相反，如果在“家庭影院〞场景中，那么等要关闭，电视要打开，扬声器要打开。引入场景概念的目的，就是为用户提供一种方便的操作方式，可以一键式的完成批量操作，而不用一项一项的去单独做。
为了实现“场景〞操作，IoTivity引入了几个概念，分别是：
1） 场景成员〔Scene Member〕，每个场景成员对应一个具体的功能资源〔OIC Server〕，以与这个具体的功能资源在特定场景下的状态。比如，一个场景成员对应一个吸尘器设备，以与吸尘器在不同场景下的动作。如果场景是“清洁房间〞，那么吸尘器的状态是打开，如果场景是“外出〞，那么吸尘器的状态就必须是关闭；
2） 场景组合〔Scene Collection〕，顾名思义，场景组合包含了多种可能的场景，比如上面讲到的智慧家庭中的“家庭影院〞，“请假房间〞等。用户可以定义多个可能的场景，然后把这些场景放在一个场景组合中，以便于管理；
3） 场景列表〔Scene List〕，是由许多“场景组合〞组合在一起，形成的一个列表。
以下图示意了智慧家庭中的两个具体场景：“清洁房间〞和“离开家庭〞。并列举了两个智慧家庭功能设备-吸尘器和智能门窗作为实例：

上图定义了一个场景组合，名字就叫做“Scenes for cleaning〞，它包含两个具体的场景：离开〔Off〕和清洁房间〔CleaningHome〕。同时场景组合包含一个叫做LastScene的属性，保存了用户最后一次操作的场景名称。同时在这个场景组合中，有两个场景成员，分别对应吸尘器和智能门窗。每个场景成员都有资源属性，记录了场景成员对应的设备的访问连接〔URI〕，同时还有一个用JSON表示的场景映射〔Scene Mapping〕属性，这是一个列表，表示了设备资源在每种场景下的状态。
这个场景组合属于一个特定的场