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

1、物联网操作系统的整体架构错误 ! 未定义书签。1.目录物联网操作系统整体架构概述错误 ! 未定义书签。a)物联网操作系统内核概述错误 ! 未定义书签。b)外围功能组件概述错误 ! 未定义书签。c)物联网协同框架概述错误 ! 未定义书签。d)公共智能引擎概述错误 ! 未定义书签。e)集成开发环境概述错误 ! 未定义书签。f)物联网领域应用概述错误 ! 未定义书签。g)物联网操作系统整体架构总结错误 ! 未定义书签。h)物联网操作系统在不同场景的应用举例错误 ! 未定义书签。2.物联网操作系统架构详解错误 ! 未定义书签。a)内核的主要组成部件错误 ! 未定义书签。i.物联网设备硬件错误 ! 未定

2、义书签。ii.硬件抽象层（ HAL）错误 ! 未定义书签。iii. 设备管理框架及设备驱动错误 ! 未定义书签。iv. 任务管理错误 ! 未定义书签。v. 内存管理错误 ! 未定义书签。vi. 中断管理错误 ! 未定义书签。vii.内核同步错误 ! 未定义书签。viii.安全与权限错误 ! 未定义书签。ix. 内核统计错误 ! 未定义书签。x. 应用管理错误 ! 未定义书签。xi. 内核 API错误 ! 未定义书签。b） 外围功能组件的主要组成部件错误 ! 未定义书签。i.在线更新错误 ! 未定义书签。i.安全与权限管理错误 ! 未定义书签。ii.内核统计错误 ! 未定义书签。iii.硬件抽象

3、层（ HAL）错误 ! 未定义书签。3.可伸缩机制：内核能大能小错误 ! 未定义书签。ii.iii.iv.v.vi.vii.c)d)e)2.a)b)i.ii.iii.c)i.ii.iii.d)e)C 运行库安全传输协议TCP/IP协议栈Java虚拟机文件系统图形用户界面物联网协同框架主要功能描述公共智能引擎主要组成部件集成开发环境主要功能描述内核：专为物联网而生物联网操作系统内核概述物联网操作系统内核的特点任务管理子系统任务管理子系统概述任务的状态及切换任务调度算法内存管理子系统内存管理概述物理内存管理算法 -空闲链表法物理内存管理算法 -固定内存块链表法设备管理子系统内核辅助子系统错误 !

4、未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。a)基于宏定义的编译配置错误 ! 未定义书签。i.内核对象签名错误 ! 未定义书签。b)基于列表的模块加载错误 ! 未定义书签

5、。c)可加载外部模块错误 ! 未定义书签。4.任务管理：兼顾效率与扩展性错误 ! 未定义书签。a)线程调度错误 ! 未定义书签。b)内核同步错误 ! 未定义书签。c)内核休眠：能节电就节电错误 ! 未定义书签。5.内存管理子系统错误 ! 未定义书签。a)固定尺寸内存块链表：确保内存分配时间错误 ! 未定义书签。b)空闲内存块链表：充分提升内存使用效率错误 ! 未定义书签。c)基于硬件MMU 的内存保护错误 ! 未定义书签。d)内存对齐错误 ! 未定义书签。e)内存清零错误 ! 未定义书签。f)基于硬件MMU 的内存空间隔离错误 ! 未定义书签。6.设备管理子系统错误 ! 未定义书签。a)中断管

6、理错误 ! 未定义书签。i.中断管理概述错误 ! 未定义书签。ii.毫秒级时钟中断错误 ! 未定义书签。iii.中断嵌套技术错误 ! 未定义书签。iv.可控锁中断技术错误 ! 未定义书签。v.中断扼杀机制错误 ! 未定义书签。b)设备命名与标识错误 ! 未定义书签。c)总线管理错误 ! 未定义书签。d)设备驱动程序错误 ! 未定义书签。7.内核辅助子系统错误 ! 未定义书签。a)内核的安全与可靠性错误 ! 未定义书签。ii.看门狗技术错误 ! 未定义书签。7.文件系统错误 ! 未定义书签。8.图形用户界面错误 ! 未定义书签。四、物联网操作系统协同框架错误 ! 未定义书签。1.物联网协同框架综

7、述错误 ! 未定义书签。iii.iv.v.vi.b)i.ii.c)i.ii.iii.d)i.ii.iii..5.6.限制队列机制基于染色的堆栈异常检测隔离数据区机制加密与验证内核效率保障机制系统时钟动态调整Direct Ethernet 技术内核统计CPU占用率统计内存分配统计中断统计硬件抽象层硬件抽象层主要功能非对齐访问CPU大头与小头物联网操作系统的外围功能组件外围功能组件概述JAVA虚拟机：实现软硬件分离在线更新机制用户界面（ shell ）数据加密与安全套接字（ SSL）简化的TCP/IP协议栈错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未

8、定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。a)低功耗连接协议错误 ! 未定义书签。viii.IoTivity 场景管理器错误 ! 未定义书签。ix.IoTivity 软件定义传感器错误 ! 未定义书签。x.IoTivity 服务目录错误

9、 ! 未定义书签。xi.IoTivity 多协议通信网关错误 ! 未定义书签。i.CoA P协议错误 ! 未定义书签。b)标准化的操作模式错误 ! 未定义书签。c)设备全局标识错误 ! 未定义书签。d)Restful 资源标识错误 ! 未定义书签。e)设备配置与激活错误 ! 未定义书签。f)设备发现错误 ! 未定义书签。g)设备认证与权限管理错误 ! 未定义书签。h)设备交互错误 ! 未定义书签。2.IoTivity框架错误 ! 未定义书签。a)IoTivity协同框架概述错误 ! 未定义书签。b)IoTivity协同框架主要功能错误 ! 未定义书签。c)IoTivity协同框架整体架构错误

10、! 未定义书签。i.IoTivity的核心服务层错误 ! 未定义书签。ii.IoTivity的附加服务层错误 ! 未定义书签。d)IoTivity主要技术实现错误 ! 未定义书签。i.IoTivity的软件架构错误 ! 未定义书签。ii.IoTivity的资源标识及标准操作模式错误 ! 未定义书签。iii.IoTivity设备的初始化错误 ! 未定义书签。iv.IoTivity设备注册错误 ! 未定义书签。v.IoTivity设备的发现机制错误 ! 未定义书签。vi.IoTivity设备信息获取错误 ! 未定义书签。vii.IoTivity 设备配置修改错误 ! 未定义书签。e)IoTivit

11、y 开发实例错误 ! 未定义书签。六、物联网操作系统开发环境与运行支撑体系错误 ! 未定义书签。1.开发环境错误 ! 未定义书签。2.运行支持机制错误 ! 未定义书签。a)物联网操作系统辅助平台错误 ! 未定义书签。五、f)3.g)h)i)i.ii.iii.iv.j)i.ii.iii.iv.k)l).4.IoTivity 优点和不足分析Google Weave 框架Weave 背景及定位Weave 的主要特点Weave 的整体架构LibWeave 和 uWweave智能手机客户端Weave CloudWeave APIWeave 的主要技术实现标准的命令和状态 Schema用户权

12、限管理针对低功耗蓝牙的深度优化针对资源受限系统的专门设计Weave 开发举例Weave 优点和不足分析不同协同框架的对比分析公共智能引擎公共智能引擎概述公共机器学习引擎DSL语言与处理引擎语音与语义识别引擎错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签

13、。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。错误 ! 未定义书签。b) 开发社区支持错误 ! 未定义书签。错误 ! 未定义书签。c) 物联网领域应用1. IoTivity 框架a） IoTivity 协同框架概述我们知道， 由于缺乏标准， 不同的物联网设备和系统之间直接交互非常困难，这样就无法实现物联网的“协同”特性。比如有的设备支持低功耗蓝牙（BLE），有的设备支持 WiFi ,有的物联网设备则支持Zigbee,这些设备之间因为缺乏统一的通信标准,相互之间无法通信。为了解决不同物联网设备之间的互通问题， 由高通， Microsoft，Intel 等等业界顶级的 IT公

14、司组成了一个叫做开放互联联盟（ Open Interconnect Consortium，OIC）的组织（后续简称为OIC）,专门制定不同物联网设备之间的互联通信标准。目前来说，参与OIC的公司，已经超过了 100多家。OIC定义了一套完整的设备之间的通信标准，只要物联网设备遵循这些标准，相互之间就可以相互通信，并能够相互协同工作。OIC是由很多不同职责的小组组成的，其中核心小组（Core Group）定义了开放互联标准的最核心机制，包括基本的通信协议，安全保证机制，设备命名和资源发布机制，等等。另外还有很多专注于“垂直”应用的小组，比如智慧家庭，工业应用，智慧医疗等。这些垂直应用小组基于核心

15、小组定义的基本机制，来进一步细化和定义垂直领域相关的通信标准。所有这些不同的小组定义的标准，组成了OIC的开放互联标准体系。同时，OIC还设计了认证机制，通过 OIC认证的设备，可以确保能够跟其它功能相关（比如，属于同一垂直领域）的设备进行直接交互，而不管这些设备是不是由同一个厂商开发的。在当前代码为王的时代， 只有标准是远远不够的，还必须有与之配套的实现代码， 以供物联网设备商直接参考。 于是在 Linux 基金会的支持下，OIC专门成立了一个叫做"IoTivity ”的项目，用于实现OIC制定的物联网设备互联标准。从IoTivity 的名字就可以看出来，这个项目就是瞄准物联网（l

16、oT）的。本质上， IoTivity 是一个开源项目的名字，这个项目的目的是为了实现OIC 定义的开放互联标准。这个项目最终实现的软件，也被成为 IoTivity 框架，在本书中叫做“ IoTivity 协同框架”,强调物联网的“协同”特性。b)loTivity协同框架主要功能C)loTivity协同框架整体架构loTivity是一个典型的物联网协同框架，其软件组成，也符合物联网协同框架的组成三要素-人侧软件，物侧软件和云侧软件。下图示意了loTivity的软件组成:I oTIvityCloud其中loTivity Client就是运行在用户智能手机,电脑，PAD等设备上的人侧软件。而loTi

17、vityDevice则是运行在物联网设备上的物侧软件，也是loTivity项目重点开发和实现的软件，在接下来的部分中，我们重点介绍loTivity Device，及物侧软件。loTivity Cloud是最新版本的loTivity推出的一项服务，它实现了一个简单的物联网后台系统。需要注意的是，loTivity Client可以通过本地局域网，直接控制loTivity设备，无需经过loTivity后台。前提是loTivity Client和loTivity Device能够位于同一个本地局域网上，能够通过WiFi，蓝牙或者 Ethernet等网络技术直接通信。这与物联网协同框架中定义的人侧软件和

18、物侧软件交互机制相同。在loTivity的实现中，Client通过CoAP协议与物联网设备交互。CoAP协议是基于IP/UDP协议的一种低功耗通信协议，该协议通过利用IP的组播功能，实现了设备的发现机制。具体来说，就是运行loTivity Client的设备，比如手机，电脑等，在本地局域网上发送设备发现请求(Device Discovery)，该请求是一个组播IP报文，会被所有运行loTivity Device的物联网设备接收到。在请求报文中，Client会指定待发现的设备类型，比如智慧灯泡，智慧门锁，等等。接收到发现请求的物联网设备，首先匹配自己的设备类型与请求报文中的设备类型，如果一致，则

19、单独给Clie nt 个回应。如果不匹配，则直接丢弃该发现报文，不做任何回应。通过这种机制，loTivity Client就会把局域网中的所有物联网设备“收集上来”，并呈 现给用户，从而完成管理和控制功能。这个过程中，还涉及到认证，权限管理，加密等等细 节，在后面的部分中，我们会详细介绍。相对运行在物联网设备上的loTivity Device软件，loTivity Client和loTivity Cloud的比重loTivity提供了这两类软件的基本组态（各类可直接链接的代码库），在具体物联网软件开发中，直接引用即可，定制的工作量并不大。下面详细介绍运行在物联网设备中的loTivity Dev

20、ice 软件。F图示意了 loTivity Device的整体技术框架:都比较少，属于“附属功能”，因此在本书中不做详细介绍。更方便的是,运行全部的loTivity协议栈，而功能受限设备，则只运行loTivity的核心服务层。因为loTivity整个loTivity的功能大致分为三层：最底层是核心服务层（Base Layer），中间一层是 loTivity服务层，最上层是具体的物联网应用，比如智慧家庭，智慧医疗，等等。同时为了处理上的方便，loTivity把目标设备分为了两类，一类是功能和资源丰富的智 能设备（称为Rich device，后续翻译为智能设备），比如手机，家庭网关，智慧电视等。这

21、类设备具备强大的 CPU处理能力，具备几百兆甚至数G的内存，具备丰富的通信能力。另外一类叫做小型设备（Lite Device，后续翻译为资源受限设备），这类设备的计算能力和通信在这两类设备中，智能设备能力往往很局限，比如一些基于嵌入式控制器的嵌入式系统等。的服务层需要相对强大的处理能力和计算资源，因此一般情况下无法在资源受限系统中运 行。核心服务层是loTivity的核心，所有其它的层次，都是基于基本服务层进行构筑的。核 心服务层包括设备发现，设备消息交互，通信安全，以及一个抽象的连接层。核心服务以 语言实现，通过C语言API向上层提供接口，供上层功能调用。核心服务层保留了最基本的 功能和服务

22、，因此对硬件设备的要求不高，可以运行在资源受限设备上。loTivity服务层则实现了常见的补充功能，包括物联网设备管理，物联网设备的数据管理，低功耗支持，资源封装，资源容器等功能。 该层次是基于loTivity的核心功能层实现的。与核心功能层不同，loTivity服务层是以C+语言实现，其 API也是基于C+语言的。这个功能层对硬件计算能力和通信能力有较高的要求，大部分情况下都运行在智能设备上，很少（或 没有）运行在资源受限设备中。最上层则是具体的应用层，比如智慧家庭，远程医疗，智慧城市等等。这些应用程序通 过调用loTivity的API接口（包括loTivity的服务层API接口，以及loT

23、ivity的核心层API接口 ），来实现特定的垂直功能。这部分内容是于具体的应用领域强相关的。需要强调的是，应用层APP并不是只能调用loTivity服务层的API接口，也可以调用 loTivity的核心服务API,需要根据实际需要具体实现。F面重点介绍loTivity的核心服务层和loTivity服务层，应用层因为与具体的垂直领域有关，在此不做重点说明。i. loTivity的核心服务层F图示意了 loTivity核心服务层的主要构成:LayerMr*矗射I呷ISerwr-tyUutthUCtConn«<1ivvtftIRffmofcflCloudDTL5PkvsnnicFA

24、IiaIi jjrtianInrtfSRMD-lockwitc- Trwiifcr屉.OUrevJrtrMpoetrfiriCoAP阳4呷对三个大类，每个大类中的每个模块进行具体说明。loTivity的设计目标之一，就是支持多种现有的通信技术或协议，比如低功耗蓝牙,loTivity专门定义了一6L0WPan, WiFi（IPv4和IPv6）,以及支持远程连接的XMPP等协议。为了屏蔽这些不同协议或技术的细节，使得上层软件能够一致的访问不同的底层通信协议, 个通信抽象层(Connectivity Abstraction Layer， CAL)。所有的底层通信技术的实现细节，都隐藏在通信抽象层之下

25、。通信抽象层提供了一个公共的平台层，为构筑在CAL之上的软件，比如C Stack，安全机制等提供了统一的接口。同时，CAL还针对不同的底层通信技术，也向上提供了特定通信技术有关的功能接口，供上层 软件按需调用。对资源服务器来说，CAL提供了组播报文的接收功能，以便资源服务器能够接收到来自客户端的资源发现请求。同时，CAL也提供了针对资源受限设备的“组播禁止”功能，以便于这些资源受限设备能够按需禁止组播，以节约能耗。ii. IoTivity的附加服务层附加服务层（在loTivity框架中叫做Service Layer，为了与核心服务区别，翻译为"辅这些公助服务层”）是loTivity基

26、于基础服务层开发的支撑物联网特定场景应用的公共服务,共服务以组件化形式存在，每个服务服务都提供特定的API （C+语言），供开发者调用，来实IoTivity也不会开发。系统内核与外围功能组件之间的关系。同时,IoTivity的附加服务层的功能组件也不是固定现某个特定的功能。这些辅助服务都有比较广泛的普适性，否则IoTivity附加服务层依赖于IoTivity的核心服务层，需要调用核心服务层提供的APl（C语言API），来完成特定的操作。IoTivity附加服务层与核心服务层的关系，类似于物联网操作的，而是随着IoTivity的发展，以及应用场景的变化，而不断变化和增加。F图示意了 IoTivi

27、ty附加服务层的主要构成:对五个大类，以及每个大类中的每个模块，进行具体说明。d）loTivity主要技术实现在对loTivity的整体架构和主要功能有了初步的了解之后，我们再深入loTivity内部，看loTivity的开发者编写看loTivity主要模块（或功能）的技术实现。本部分内容主要是面向 的，通过对loTivity的内部实现有清晰的了解，可以帮助开发者更好的实现应用程序。i. loTivity的软件架构上面介绍了 loTivity的功能架构，下面简单介绍其软件架构。下图示意了 loTivity的软件分层结构:Ap plicaUonsIdIi viTy ServiceSDK)CoAP

28、Wifi/rt'hernel/.在软件实现上，loTivity基于清晰的层次结构。图中最上面和最下面两层，分别是物联网应用程序和网络硬件，严格来说不属于loTivity的范畴。当前的loTivity实现是基于CoAP协议作为其基础通信协议，我们知道，CoAP协议基于UDP/IP协议实现。loTivity的整个软件体系又进一步分为核心功能层和附加服务层，其中核心服务层就在上图中loTivity Base这个软件层次中实现，这包括设备发现，远程访问等等基础能力。核心服务层的API是基于C语言实现的，可以很方便的移植到资源受限的嵌入式系统中。在核心服务层之上，就是loTivity的附加服务层

29、。该层次通过C+语言实现其API,并实现了诸如easy set up. Group Ma nager等基础服务。如果loTivity是面向资源受限的硬件设备，则只需要移植核心服务层即可。如果是面向资源不受限的智能硬件平台， 同时又需要支持完整的 IoTivity 附加服务， 则需要移植基于 C+基于 IoTivity 的物联网应用程序，向 IoTivity 核心代码库进行注册。这些软件都运行在同一台物联网设备中。因此严格来说，这里的注册，应该是“不同软件模块之间的信息交互”O的附加服务层。ii. IoTivity 的资源标识及标准操作模式iii. IoTivity 设备的初始化分为两类： 一类

30、是针对特定应用场景的批量初始化， 比如智慧路灯， 智慧商场中的各类传感器，等等。这类设备在设备投放使用之前，就已经完成初始化，比如设备的蓝牙 PIN码,WiFi密码及SSID服务器端的IP地址或者域名，以及各类参数。这类设备的初始化，一般是由系统集成商来定制完成的。 这类设备的初始化过程比较简单直观， 只需要在设备的软件中预置相关参数即可，本文不做深入描述。另外一类设备是面向消费者的设备， 比如智慧灯泡，智慧家电，等等。这类设备是面向海量用户市场，每个用户的设置和运行环境都不一样，比如用户A 的 WiFi 密码，与用户 B的 WiFi 密码就不一样，这样就无法做到出厂时的初始化，必须在用户购买

31、之后，针对其特定的应用环境完成初始化。为了完成这项初始化的工作，IoTivity 提供了一些可选的服务和机制，本文中进行详细描述。iv. IoTivity 设备注册IoTivity 协议栈提供了公共的设备资源管理能力，任何基于 IoTivity 开发， 并向外提供物联网服务的设备，比如智慧灯泡，智慧空调等，都需要把自己提供的功能注册到IoTivity 的核心协议栈中。只有注册到 IoTivity 的设备资源，才能被 IoTivity Client 发现。需要注意的是， 这里的注册， 并不是物联网设备向物联网后台等云端软件的注册，而是图示意了这个逻辑：注册响应loTivity提供的API注册Bo

32、TiyiT协仪栈注册的工作，由物联网设备应用程序完成。设备应用程序调用自己，下图示意了这个过程:BVServer5SDKStrwirWrpperCbnutmalji|1 ula 加 n.fJ r：£ |=.J1->Mure</JiKzess-在注册的时候，物联网应用程序（ISV Server App）调用 C+ SDK提供的 registerResource函数（该函数属于一个叫做platform的对象），该函数进一步调用 C SDK提供的API,最终在success,IoTivity的核心中完成注册。如果这个过程一切正常，那么最终会返回给应用程序任何一个步骤失败，都会返

33、回failure。物联网应用程序在注册资源的时候，需要指定资源的URI，资源的类型（比如智慧灯泡, 智慧门锁等），例如下面的代码示例:OCResourceHa ndle resourceHa ndle;std:stri ng resourceURI = "/light/ 1"std:stri ng resourceT yp eName =""std:stri ng resourceI nterface = DEFAULT_INTERFACE;uin t8_t resource Property = OC_DISCOVERABLE | OC_OBSERVA

34、BLE;OCStackResult result = (resourceHandle, resourceURI,resourceTypeName, resourceInterface, &entityHandler, resourceProperty);if (OC_STACK_OK = result)/SuccessfullURI（代码中的resourceURI）用于loTivity Client访问资源的唯一链接（或标识）。需要注意的是，物联网应用程序在调用registerResource的时候，指定的是 URI的一部分。loTivity核心服务会把物联网设备的 IP地址及端口号附

35、加在前面， 形成一个完整的URI。在这个实例中,如果物联网设备的IP地址是：，则loTivity形成的完整的URI是：,物联网设备对应的服务资源就呈现在 IoTivity 整体框架中了，这时候 IoTivity Client 就可以通过资源发现机制，发现相应的物联网资源，并进行调用或控制。v. IoTivity 设备的发现机制IoTivity Client （物联网协同框架的人侧软件）是通过发现机制（Discovery）来发现IoTivity服务器，并建立关联关系，从而完成管理和控制。一般情况下，IoTivity Client 和所有提供服务的IoTivity Server在同一个局域网内，比

36、如都位于家庭WiFi网络中。 Client 在整个局域网上发送 Discovery 组播，在组播报文中携带了希望发现的资源类型，比如智慧灯泡，智慧门锁等。运行 IoTivity 协议栈的所有物联网设备都会收到这个组播消息。但是只有设备类型符合的物联网设备，才会向Client发送一个回复。在这个回复中，包含了资源URI等信息，Client可以通过URI直接访问到该资源。下图示意了这个过程:ClientLightL92.16S.L.11Light2Fan1；ut. Ltj nji'r '1=1 ;,r" l,mirjlkt.Ll

37、j!llJI f si In CK cnflTEt-Jr-VWX.CCiNH%-QIIQQq在该实例中，Client通过IP组播(multicase)，发送一个获取资源类型是“智慧灯泡”(oc/corert=light )的发现请求。组播报文会被所有运行IoTivity协议栈的设备收到，在这个只有智慧灯泡的资源类型图中，共有三个物联网设备，其中两个是智慧灯泡，一个是风扇。匹配Client发出的发现请求，因此这两个智慧灯泡(IP地址分别是和)分别向Client发送一个回复消息。Client收到这两个回复消息之后，就知道在这个网络上，有两个智慧灯泡，于是会存储这两个智慧灯泡的相关信息，并呈现在用户

38、界面中。用户就可以对这两个智慧灯泡进行操作 了。loTivity SDK上面描述的是资源发现的业务逻辑，在实际操作上，IoTivity Client必须调用提供的API,来启动发现过程。下图示意了发现过程中的函数调用关系:ISVClient AppSDKIntarnillOCStidc(IpitWIMlNatweittCoAPI.:-pijtk：-rri H hd=lL-:?Ur=4?l-J3| 匸.,i OC'boRciaT,-ize； J=卜C UJ H = = =F dilu ft/pendinF 一I；! -I专ml IHriF urfih广叫mm 门“心问i hnWkfMra

39、 ApE 产 A那fKe" backr inc54| UnlCJtiFiHPCnt*frflm 192 1M t itfo InvnkeiJrapOeAiycCsHtOCiFunC15b UNcBSt mporseIremClient APP首先调用SDK提供的findResource函数，启动资源发现过程。在调用这个函数时，需要指定待发现的资源类型，以及一个回掉函数。因为资源发现是异步过程，也就是IoTivity注册一个回掉函数,说Client APP无法事先知道什么时候会返回结果，因此只能向在IoTivity收到物联网设备返回的应答消息后，会调用这个回掉函数，通知Client A

40、PP,已经发现了想要的资源。SDK的findResource函数进一步调用loTivity Client封装层提供的findResource函数，封装层再调用loTivity核心服务层提供的 OCDoResource函数，这个函数构造一个CoAP报文,并把该CoAP报文封装在一个组播IP报文中，发送到网络上。网络上的物联网设备收到发现请求消息之后，会匹配资源类型，如果类型匹配，贝y以单 播（uni cast）形式，向IoTivity Clie nt APP回复一个发现应答。这个应到被 IoTivity核心服务层收到，核心服务层调用SDK注册的回掉函数，最终调用到Client APP在调用fin

41、dResource时注册的回掉函数。这样Clie nt APP就可以收到资源发现的应答，从而记录资源信息，并向用户呈现，接收用户的控制。让我们把资源发现的目光再深入到网络层，看看IoTivity Client 和 IoTivity 资源服务器之间的报文交互。运行在Client上的IoTivity核心服务层会根据 findResource函数指定的参数,构造一个CoAP协议数据报文，并以组播方式发送到网络上。下面的表格示意了构造的 CoAP报文:FieldValueNote(s)Address组播IP地址及端口号HeaderNON,GET,MID=0x7d40资源发现请求是不需要回复确认 的UR

42、I-Pathoc"/oc/corert="URI-PathcoreURI-Queryrt=Acce ptapp licati on/json接收响应的内容格式Client通过组播方式，把Discovery报文发送到网络上。是一个组播地址，所有运行IoTivity的物联网设备都会监听这个地址，可以接收到任何被发送到这个组播IP地址的报文。5683是对应的UDP端口号。CoAP的报文类型是NON,即不需要接收端确认。因为这个报文会被多个物联网设备接收到,因此无法采用确认机制。CoA P请求的方法是GET即获取地址。消息 I D(MID)是 0x7d40。最关键的信息，是CoAP

43、报文的选项（Option ）。这个资源发现报文包含了两个URI-Path选项，一个待发现的资源类型，以及一个可以接收的内容解析格式（JSON。这里也可以看出，通过携带多个 URI-P ath选项，就可以形成一种层次化的目录格式。比如在这个例子中,两个URI-Path结合起来，就形成了 ”/oc/core ”这样一个层次化路径。CoAP报文中携带的URI路径信息，与目标主机的IP地址或域名结合起来，就形成了一个完整的 URI。比如而待发现的资源类型选项（URI-Query），则指定了感兴趣的物联网设备类型。在这个例子中，是智慧灯泡（）。可以通过修改资源类型，来发现其它物联网设备，比如传感器（se

44、nsor），门锁（lock），等等。最后一个选项 Accept，指明了响应报文中的内容格式，即如果被发现设备响应这个发现请求，应该以什么样的数据格式来描述自己。在这里,Client希望收到以JSON格式描述自身属性的发现响应。网络上所有运行IoTivity的物联网设备，都会接收到这个资源发现请求（网络异常情况, 比如丢包等，不做考虑）。物联网设备会解析 CoAP资源发现请求，用自己的资源类型去匹配请求的资源类型（即）。如果不匹配，则忽略该响应，如果匹配，则回复一个发现应答消 息。下表示意了来自IP地址是的响应:FieldValueExplan ati onAddressAddressACKHe

45、aderCONTENTSuccess w/c ontentMID=0x7d40Contentapp licati on/jsonloTivityFieldValueExplan ati onFormatPayload "href" : "/light/1", "rt":"","if":"","obs":1与资源发现请求不同，发现响应报文是单播报文，目标设备直接把响应发送给Client。在响应报文中，CoAP报文类型是 ACK,响应报文的消息ID(MID)与

46、资源发现报文相同，都是0x7d40,标识了同一个会话。而CoAP的Content Format选项，与资源发现请求的Accept选项相对应，都是 JSON格式。在响应报文的负载中，包含了设备的具体信息，比如设备的URI是“ /light/1 ”，类型是light，等等。需要注意的是，响应报文的URI，与设备的IP地址组合起来，就是设备的完整URI，在这个例子中，是，IoTivity Client可以通过访问这个URI，来操作物联网设备。vi. IoTivity设备信息获取IoTivity通过发现过程，把网络上的物联网设备收集起来。这时候用户就可以通过IoTivityClient的GUI，看到网

47、络上的所有物联网设备及设备类型了。如果用户选定某一个物联网设备，比如智慧灯泡，希望进一步查看选定物联网设备的信息(比如智慧灯泡当前的亮度及颜 色信息)，则会触发IoTivity设备信息获取流程。下图示意了这个过程:ISVClfamAppdentSDK：lentWrapperUiirtemaOClientOCStackUntemahServerOCStacfclirtemal)Clientwrapper(internal)ScfvefSDKISVServerftppirI.? 1. lilt j LI? IrPraeditnjeiCet 'hKkJ|3W氐七a?址IMhaaca hma5

48、 fill WTl卸伽咕！fI；I耐 HI >00起q蛋；Uaiace Rmp111 ACK, COYTEfT|13 fttfiLfne&dfl p Retire cede ；A Return*- T r":引 I'VESkj-鑒-萃丽匚R廿2 5 口色肝 W-U 护IS札金I hrfArurtc(1)loTivity Client调用SDK提供的函数，试图获取目标设备的状态信息。在调用该函数的时候，需要指定一个回掉函数。在物联网设备的状态信息返回之后，IoTivity会调用这个回掉函数，通知IoTivity Client结果;SDK的get函数会进一步调用内部

49、封装层提供的get函数;内部封装层的 get函数会调用loTivity的C API函数OCDoResource该函数会根据传递过来的参数，比如目标设备的URI，来构造一个(4)(6)CoAP报文，然后发送到网络上。这个CoAP报文的方法是 GET里面携带了目标设备的 URI;这个CoAP报文跨越网络，被发送到目标物联网设备;目标物联网设备的IoTivity核心服务代码分析CoAP报文，根据URI来调用对应的处理函数。针对不同的CoAP方法，比如 GET, PUT,POST等等，IoTivity核心服务层都有对应的处理函数。在这里会调用GET处理函数;IoTivity的GET处理函数会进一步调用

50、封装层提供的OCResource函数，该函数会进一步通过 C+ SDK的框架代码，调用到最终物联网服务的处理函数;(7)物联网服务处理函数根据请求类型，返回处理结果。这个处理结果一(8)直返回到物联网设备的IoTivity核心服务层（对应图中的8/9/10三步）;物联网设备的loTivity核心服务层构造一个CoAP协议报文，该报文的类型是ACK里面携带了具体的内容。物联网设备把这个 CoAP报文发送到网络上，最终到达IoTivity Client ；(9)经过几个回掉，loTivity Client端代码最终调用到客户指定的回掉函数，把设备返回结果提交给用户代码。用户代码在回掉函数中，会 把获取到的信息（比如智慧灯泡的亮度）显示给最终用户。F面我们在深入到上述过程中构造的两个CoA P报文，看看它们的构成，会对这个过程有更进一步的理解。下表示意了由IoTivity Client发出的CoAP报文:FieldValueNote(s)Add