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

. . . . . 目录一、物联网操作系统的整体架构51.物联网操作系统整体架构概述5a)物联网操作系统核概述5b)外围功能组件概述6c)物联网协同框架概述6d)公共智能引擎概述8e)集成开发环境概述8f)物联网领域应用概述8g)物联网操作系统整体架构总结9h)物联网操作系统在不同场景的应用举例102.物联网操作系统架构详解10a)核的主要组成部件10i.物联网设备硬件11ii.硬件抽象层HAL11iii.设备管理框架与设备驱动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.硬件抽象层HAL203.可伸缩机制：核能大能小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.用户界面shell275.数据加密与安全套接字SSL276.简化的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地址是：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报文：FieldValueNote(s)Address224.0.1.187:5683组播IP地址与端口号HeaderNON,GET,MID=0x7d40资源发现请不需要回复确认的URI-Pathoc/oc/core?rt=alpha.lightURI-PathcoreURI-Queryrt=alpha.lightAcceptapplication/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的响应：FieldValueExplanationAddress192.168.1.1: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，在这个例子中，是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报文：FieldValueNote(s)Address192.168.1.11: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报文：FieldValueExplanationAddress192.168.1.1:5683Client AddressHeaderACKCONTENT,MID=0x7d42Success w/ContentContentTypeapplication/jsonPayloadpower : 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属性，这是一个列表，表示了设备资源在每种场景下的状态。这个场景组合属于一个特定的场