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

目录一、物联网操作系统的整体架构51.物联网操作系统整体架构概述5a)物联网操作系统内核概述5b)外围功能组件概述6c)物联网协同框架概述6d)公共智能引擎概述8e)集成开发环境概述8f)物联网领域应用概述8g)物联网操作系统整体架构总结9h)物联网操作系统在不同场景的应用举例102.物联网操作系统架构详解10a)内核的主要组成部件10i.物联网设备硬件11ii.硬件抽象层（HAL）11iii.设备管理框架及设备驱动11iv.任务管理11v.内存管理11vi.中断管理12vii.内核同步12viii.安全与权限12ix.内核统计12x.应用管理12xi.内核API12b)外围功能组件的主要组成部件13i.在线更新13ii.C运行库13iii.安全传输协议13iv.TCP/IP协议栈13v.Java虚拟机13vi.文件系统13vii.图形用户界面13c)物联网协同框架主要功能描述14d)公共智能引擎主要组成部件14e)集成开发环境主要功能描述14二、内核：专为物联网而生142.物联网操作系统内核概述14a)物联网操作系统内核的特点14b)任务管理子系统14i.任务管理子系统概述14ii.任务的状态及切换15iii.任务调度算法17c)内存管理子系统18i.内存管理概述18ii.物理内存管理算法-空闲链表法18iii.物理内存管理算法-固定内存块链表法20d)设备管理子系统20e)内核辅助子系统20i.安全与权限管理20ii.内核统计20iii.硬件抽象层（HAL）203.可伸缩机制：内核能大能小20a)基于宏定义的编译配置20b)基于列表的模块加载20c)可加载外部模块204.任务管理：兼顾效率与扩展性20a)线程调度20b)内核同步21c)内核休眠：能节电就节电215.内存管理子系统21a)固定尺寸内存块链表：确保内存分配时间21b)空闲内存块链表：充分提升内存使用效率21c)基于硬件MMU的内存保护21d)内存对齐21e)内存清零21f)基于硬件MMU的内存空间隔离216.设备管理子系统22a)中断管理22i.中断管理概述22ii.毫秒级时钟中断22iii.中断嵌套技术23iv.可控锁中断技术23v.中断扼杀机制23b)设备命名与标识24c)总线管理24d)设备驱动程序247.内核辅助子系统24a)内核的安全与可靠性24i.内核对象签名24ii.看门狗技术24iii.限制队列机制24iv.基于染色的堆栈异常检测24v.隔离数据区机制24vi.加密与验证24b)内核效率保障机制24i.系统时钟动态调整24ii.Direct Ethernet技术24c)内核统计25i.CPU占用率统计25ii.内存分配统计25iii.中断统计25d)硬件抽象层25i.硬件抽象层主要功能25ii.非对齐访问25iii.CPU大头与小头25三、物联网操作系统的外围功能组件251.外围功能组件概述252.JAVA虚拟机：实现软硬件分离263.在线更新机制274.用户界面（shell）275.数据加密与安全套接字（SSL）276.简化的TCP/IP协议栈277.文件系统278.图形用户界面27四、物联网操作系统协同框架271.物联网协同框架综述27a)低功耗连接协议29i.CoAP协议29b)标准化的操作模式34c)设备全局标识34d)Restful资源标识34e)设备配置与激活34f)设备发现34g)设备认证与权限管理34h)设备交互352.IoTivity框架36a)IoTivity协同框架概述36b)IoTivity协同框架主要功能36c)IoTivity协同框架整体架构36i.IoTivity的核心服务层38ii.IoTivity的附加服务层39d)IoTivity主要技术实现39i.IoTivity的软件架构40ii.IoTivity的资源标识及标准操作模式40iii.IoTivity设备的初始化40iv.IoTivity设备注册41v.IoTivity设备的发现机制42vi.IoTivity设备信息获取45vii.IoTivity设备配置修改47viii.IoTivity场景管理器47ix.IoTivity软件定义传感器49x.IoTivity服务目录49xi.IoTivity多协议通信网关49e)IoTivity开发实例49f)IoTivity优点和不足分析493.Google Weave框架49g)Weave背景及定位49h)Weave的主要特点50i)Weave的整体架构50i.LibWeave和uWweave51ii.智能手机客户端52iii.Weave Cloud52iv.Weave API53j)Weave的主要技术实现54i.标准的命令和状态Schema55ii.用户权限管理58iii.针对低功耗蓝牙的深度优化58iv.针对资源受限系统的专门设计59k)Weave开发举例60l)Weave优点和不足分析604.不同协同框架的对比分析61五、公共智能引擎611.公共智能引擎概述612.公共机器学习引擎613.DSL语言与处理引擎624.语音与语义识别引擎62六、物联网操作系统开发环境与运行支撑体系621.开发环境622.运行支持机制62a)物联网操作系统辅助平台62b)开发社区支持62c)物联网领域应用621. 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地址是：1，则IoTivity形成的完整的URI是：coap:/1: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地址分别是1和2）分别向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报文：FieldValueNote(s)Address87:5683组播IP地址及端口号HeaderNON,GET,MID=0x7d40资源发现请求是不需要回复确认的URI-Pathoc/oc/core?rt=alpha.lightURI-PathcoreURI-Queryrt=alpha.lightAcceptapplication/json接收响应的内容格式Client通过组播方式，把Discovery报文发送到网络上。87是一个组播地址，所有运行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。比如87:5683/oc/core.而待发现的资源类型选项（URI-Query），则指定了感兴趣的物联网设备类型。在这个例子中，是智慧灯泡（alpha.light）。可以通过修改资源类型，来发现其它物联网设备，比如传感器（sensor），门锁（lock），等等。最后一个选项Accept，指明了响应报文中的内容格式，即如果被发现设备响应这个发现请求，应该以什么样的数据格式来描述自己。在这里，Client希望收到以JSON格式描述自身属性的发现响应。网络上所有运行IoTivity的物联网设备，都会接收到这个资源发现请求（网络异常情况，比如丢包等，不做考虑）。物联网设备会解析CoAP资源发现请求，用自己的资源类型去匹配请求的资源类型（即alpha.light）。如果不匹配，则忽略该响应，如果匹配，则回复一个发现应答消息。下表示意了来自IP地址是的响应：FieldValueExplanationAddress:5683Client AddressHeaderACKCONTENTMID=0x7d40Success w/contentContentFormatapplication/jsonPayload 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，在这个例子中，是: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报文：FieldValueNote(s)Address1:5683Unicast packetHeaderCON, GET, MID=0x7d42Confirmation is requestedURI-Pathlight/light/1URI-Path1Acceptapplication/json这个CoAP报文的目标地址，是一个单播IP地址，直接发到一个具体的物联网设备。这与设备发现过程不同，因为在信息获取过程中，用户已经指定了一个具体的物联网设备，所以IoTivity Client会直接把GET请求发送到该设备。这个CoAP的类型是CON，即需要接收端确认。方法是GET，消息ID是0x7d42。该报文中通过两个URI-Path选项，指定了目标物联网设备上的目标资源。同时该CoAP请求指明了期望的响应数据格式为JSON。下表示意了由物联网设备返回给IoTivity Client的CoAP报文：FieldValueExplanationAddress:5683Client AddressHeaderACKCONTENT,MID=0x7d42Success w/ContentContent Typeapplication/jsonPayload 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），顾名思义，场景组合包含了多种可能的场景，比如上面讲到的智慧家庭中的“家庭影院”，“请假房间”等。用户可