泛在业务环境设备能力的汇聚与系统框架设计

时间：2015-12-20 22:15:39 所属分类：软件开发 浏览量:

1 引 言 随着信息技术的发展，人们对信息的获取和使用方式由原来的单一网络连接逐渐向泛在信息服务迁移． 在泛在业务环境中，各类信息设备被应用到生活中的各类场景中． 泛在业务环境是通过对这些无处不在的数字信息进行采集、管理、有效利用，使各类功能各

　　1 引 言

　　随着信息技术的发展，人们对信息的获取和使用方式由原来的单一网络连接逐渐向泛在信息服务迁移． 在泛在业务环境中，各类信息设备被应用到生活中的各类场景中． 泛在业务环境是通过对这些无处不在的数字信息进行采集、管理、有效利用，使各类功能各异、无处不在的网络和设备能够协同工作，实现泛在业务环境下物与物、物与人、人与现实之间的高效交互模式．如图 1 所示，传统的设备能力利用方案多是面向特定行业和场景的垂直型应用，应用开发的壁垒高，通常使用封闭的私有接口和通信协议，难以满足泛在业务环境下跨网络、跨行业的水平型应用需求． 所以，本文提出了一种系统架构，采用模块化的方法将设备映射为抽象的 web 资源，使各类应用能够通过统一的 ＲESTful( ＲEpresentational State Transfer) 接口与之实现访问和交互． 架构考虑到了泛在网中设备海量、异构、移动的特点，因此模块的划分和功能设计使架构具有较好的低耦合和可扩展性． 对设备的统一资源抽象使得这些数据源网络具备应用层的互操作能力，能够实现一个应用同时聚合使用多种设备的能力，同时，同一个设备的能力也能够被多个应用所复用，因此可以较好的满足泛在业务环境下设备能力的汇聚与开放的需求． 经过一个在具体硬件环境中实施的演示系统验证了该架构的可行性和有效性．

2 相关工作

　　早期的泛在网研究重点在于将无处不在的数字设备与现实世界进行关联整合，形成“Internet of Things”． 然而，早期应用的结构一般都是垂直方向的解决方案，每个应用通常只针对特定的场景，需要专用的软件和通信协议才能工作． 这种结构在设备数量不多，用户较少的情况下是可行的，然而它不适合泛在业务环境下大量异构设备在应用层的服务聚合与开放．为了实现较好的互操作性，研究人员尝试将传统网络中的协议移植到泛在网环境中． 6LoWPAN［3］即是这种工作的成果，它能使设备具有简单的 IPv6 通信能力． 文献［2，6，8］利用该方法在设备中植入精简的 web 服务． 但是该方案的实施过程仍然非常精细，例如，在各类异构设备上实施 6LoWPAN 本身便需要解决各类兼容性的问题，在受限设备上实施 web 服务也需要针对存储和计算能力进行专门优化． 这个过程相当于在各类设备上重新实现一套网络协议栈，成本和专业门槛较高，不适合大规模推广．在文献［4］中描述了一种通过对设备能力进行抽象，从而屏蔽异构差异，实现泛在网中可插拔式( Plug and Play) 开放服务市场的前景． 该工作缺少对下行通信的抽象方法进行讨论． 文献［7］尝试在社交网络环境中实现设备信息的共享，该工作重点考虑了实施设备信息共享时的隐私保护和接入控制等相关问题． 该工作主要针对规模和数量较小的数据源网络信息共享，缺少对泛在网中海量设备、众多数据源网络的情况下可扩展性的考虑．利用已被广泛接受和推广的技术来实现泛在设备的能力汇聚与开放是非常合适的． Web 技术的大规模普及使之具备这种条件，具有准入门槛低、易于推广的优势． 在泛在网中，通常使用 ＲEST 架构［1］的方法将设备的能力抽象成能够使用统一接口访问的 web 资源，这主要是由于其相对于其它方法更为简洁轻量的结果． 3 系统架构和组件功能

　　相比传统的传感器网络应用，在泛在业务环境下设备的能力汇聚与开放所面对的应用需求种类更多，服务范围也相对更为分散，加上泛在业务环境下设备数量众多，架构和功能各异，因此，在架构上，除了要满足对不同平台的兼容性和能力汇聚开放的需求外，还需要充分考虑整个系统的低耦合和可扩展性．系统架构如图 2 所示． 架构的设计以数据为中心，将数据源的能力汇聚与面向用户的能力开放进行分离． 系统由数据源、预处理模块、ＲESTful 接口模块、控制适配模块、数据仓储组成． 当数据从传感网中汇聚到系统中后，首先由预处理模块进行必要的规整处理，将可能来自不同网络不同类型节点的原始数据预处理成数据仓储中所要求的格式． 用户与系统之间的数据传输采用 HTTP 协议，交互过程采用 ＲESTful 风格的接口进行． 3. 1 数据源

　　数据源通常由普通传感器节点和 sink 节点组成． 普通节点通常装备有能够感知某类参数( 如温度、位置信息等) 的专用传感模块． 传感器节点采集数据后，通常通过其自身装备的无线发射模块在传感网中汇聚到 sink 节点． 根据应用需求场景的不同，传感器节点有时也需要接收和响应处理来自 sink下发的控制类请求报文．Sink 节点连接传感器网络和全功能外部设备，同时具备与传感器网络中的节点和全功能设备进行通信的能力． 普通节点的数据汇聚到 sink 节点后，由 sink 交给全功能设备上的预处理程序进行处理． 对传感器网络的控制指令也首先交由sink 节点然后向下传达．

　　3. 2 预处理模块

　　在泛在业务环境中，平台需要能够支持不同种类，功能和架构各异的数据源设备的接入． 这意味着接入平台的泛在设备的能力、上传的数据类型、数据的封装方式等等也是非常多样化的． 因此，当数据汇聚到 sink 节点后，需要由预处理模块对数据进行必要的规整和格式化操作，屏蔽差异，使之符合平台对数据格式的要求，然后将其存入数据仓储模块．举例来说，预处理通常需要完成的功能如下:

　　1) 针对各类 sink 节点上传的报文，进行相应的解析，提取出相关的数据字段; 2) 若节点为能力受限节点，不能随报文提供数据采集的时间戳信息，则预处理模块有必要在数据进入仓储模块前为其添加当前的时间信息; 3) 当数据源网络缺少标识，相互之间无法区分时，预处理模块可以在收到数据后为其添加相应的网络信息标识; 4) 如有必要，需要对采集的数据进行单位换算，或者进行异常值检测，便于统计处理; 5) 为了增加传输的效率、延长数据源网络的生命周期，数据源节点可能会积累多个感知数据后用封装到同一个报文中发出． 在这种情况下，预处理模块可能需要将其分拆开，作为单个数据条目存入数据仓储模块．

　　3. 3 ＲESTful 接口模块

　　ＲESTful 接口模块用于对泛在业务环境下的设备进行功能抽象和能力开放． 将设备的能力封装为 ＲESTful 风格的接口供外部应用系统调用． ＲESTful 接口通常使用 HTTP 协议作为数据传输的方法，接口交互时的数据封装格式一般采用较轻量的 JSON，或者 XML 格式．ＲESTful 接口的设计主要需要表达对数据源的常用操作，如数据的查询和基本控制功能，还可以通过接口的封装提供原设备不具备的能力接口，如统计相关和事务控制类的接口等．通过 ＲESTful 接口抽象层，各类设备自身的私有通信方式和协议细节被隐藏起来，应用程序接入设备的门槛可以大大降低． 同时，通过抽象层开放设备的能力，使得能够同时接入和使用数据源服务的用户数大大增加，符合泛在业务环境下对服务聚合和开放的需求．

　　3. 4 控制适配模块

　　当需要通过 ＲESTful 接口向下实施对数据源的配置功能时，由于向下传达控制指令时的网络延时和传输的可靠性难以保证，加上 HTTP 协议本身无状态的特点，对数据源的配置类指令采用事务控制和非阻塞的方式进行． 这种做法的好处是，在保证服务可用性的同时，客户端在进行数据源配置时无需考虑每类设备的细节，从而简化与数据源进行主动交互时的复杂度．控制适配模块的功能流程描述如下:

　　1) 首先，由平台的用户向 ＲESTful 接口模块调用配置相关的接口; 2) ＲESTful 接口模验证请求来源的合法性以及请求本身的完整性后，为该次配置动作创建相应的事务记录，存入事务仓储中; 将事务标识号返回给客户端． 否则，该次调用配置接口失败，执行结束; 3) 控制适配模块监控事务仓储中的事务列表，依据每条事务信息的描述内容执行不同的动作． 事务的描述字段可包括: 事务的当前状态、单次执行失败后重复次数、执行间隔、上次执行时间、事务执行动作的描述信息等． 事务的终止状态至少包括两类: 执行成功、执行失败终止; 4) 平台的用户使用之前获得的事务标识号向 ＲESTful后端模块查询事务当前的执行状态; 5) ＲESTful 接口模块验证请求完整性后，向事务仓储查询相关的事务信息，并将之返回给用户应用程序．

　　3. 5 数据仓储模块

　　在泛在业务环境中，一方面，平台需要适应来自多个数据源网络的能力汇聚和开放需求; 另一方面，平台也需要应对来自应用程序对开放接口的大量调用． 在这种情况下，在平台中将数据仓储模块独立出来单独考虑就显得非常必要，因为在大数据量和并发量的情况下，需要特别保证数据的安全和高可用性，随机接入平台的数据源网络和应用程序越来越多，随之而来的可扩展性需求也会出现． 将业务逻辑和数据仓储分离开来正是为了适应这种可扩展性的需求．数据仓储模块在本系统中主要用作两类功能:

　　1) 作为永久数据仓库存储预处理模块规范化后的传感数据; 2) 为控制适配功能提供相应的事务信息基础设施． 当用作传感数据的存储时，其中应至少包含节点标识信息、数据和数据类型描述． 当需要区分多个数据源网络时，需要包含不同网络的标识信息． 对于节点的信息，可依需求对节点型号、节点运行程序的版本号、节点配置相关的参数进行记录．当用作事务信息存储时，其中至少应包含事务标识号、事务描述信息、事务当前执行状态信息． 对于事务描述信息，其规范由控制适配模块来定义以保证相应的功能需求和兼容性． 4 系统参考实现和部署

　　系统架构的可行性和有效性通过一个在具体硬件平台上实施的参考系统来进行一步验证． 系统中传感器网络的硬件设备共有 4 种，主要为功能受限设备，它们组成数据源网络．1) 普通节点 2 种，分别是 Crossbow MPＲ 2400( MICAz) 和Crossbow MPＲ XM2110( IＲIS) ;2) Sink 节点 Crossbow MPＲ XM2110( IＲIS) ;3) Sink 节点与 PC 的接口设备 Crossbow MIB 520 USB In-terface Board;4) 传感器设备 Crossbow MTS300．传感器网络中的节点运行 TinyOS 2. 1. 0 系统，其所使用的通信协议和接入方式是专门设计的私有方法． 应用程序通过 ＲESTful 接口模块提供的接口来访问传感器网络，在演示系统中呈现给最终用户的是 Web 交互界面．具体来说，普通节点周期性地( 默认以 10 秒为周期) 在传感器网络中向 sink 节点上传数据，数据类型有两种，分别为温度值和光照强度值．预处理模块与 sink 节点通过串口进行通信，取得数据的原始报文，从中获取关键的节点标识、传感数据、数据类型信息． 由于这些节点所上传的报文中无法包含有效的时间戳信息，因此在预处理时需要对此进行添补． 另外，TinyOS 系统中节点的标识是局部唯一的，当有多个网络接入系统时，则可能会出现不同网络中设备标识符相互冲突的情况，因此预处理模块需要对不同网络进行区分，根据与之通信的 sink 节点的不同为数据添加数据来源信息． 也可以依据业务逻辑的需要，对节点标识符进行补充，使之具备全局唯一性．ＲESTful 接口模块收到客户端的查询类请求后，从数据仓储中取得信息，然后再按照接口参数的要求封装成标准的格式返回给客户端． 在演示系统中有控制类接口 1 个，用于设置节点的数据上报周期． ＲESTful 接口在收到这类请求后，通过控制适配模块注册相应的事务信息，然后将事务号返回给用户应用程序． 控制适配模块负责事务的执行，从而实现控制指令的非阻塞操作．

　　演示系统的 ＲESTful 接口设计示例如表 1 所示． ＲESTful接口模块抽象和封装出必要的数据查询接口和网络参数控制功能，还可以在此基础上提供原始数据源不具备的接口，例如基本的数据统计接口、数据可视化相关的接口等． 接口调用参数使用 HTTP 协议标准的方式编码，数据传输时的封装也使用标准的 JSON 格式编码，从而保证不同平台间的兼容性和互用性，具有易于实施和推广的优点．如图 3 所示，系统在整体上为各个接口设计了统一的应答格式． 合并具有相同语义的部分，减少了细节差异，从应用开发人员的角度看使得接口整体具有相互关联的一致性．

　　图 4 为某次调用/QueryData 的结果示例，该次调用为数据查询类的调用，查询结果使用 JSON 进行封装表示． status字段的值为 0，reason 字段的值为”ok”，它们表示此次调用成功． 查询结果中数据负载的封装和表示需要依据各个接口的功能需求而分别定义，此处使用 JSON 的 object 类型进行表示． 其中，dataset 字段为 array 类型，用于封装满足查询条件的数据集． 每个数组元素又使用 object 对象封装，包含有 data、sn、ts、id 等 4 个字段，分别表示光照值、数据的序号、数据的时间戳、数据源的节点标识符． 数据负载中还含有数据集的简单统计信息，由平台计算后返回给应用程序，封装在字段 min、max、median、mean、std _dev 中，分别表示最小值、最大值、中值、平均值、标准差。

　　5 结束语

　　本文针对泛在业务环境下设备的接入和交互问题，设计了一种基于 ＲEST 的能力汇聚与开放系统架构． 考虑到泛在网中设备数量大、异构、移动等特点，系统的设计采用了模块化划分的方法，模块的划分方式保证了平台的低耦合和可扩展性． 与传统方法中客户端与数据源一对一交互的模式相比，采用 ＲEST 架构方法对数据源能力进行抽象，使得同一个数据源的能力能够同时应用到多个应用中去，同一个应用可以使用统一的接口来访问多个不同的数据源能力． 标准的通信和交互接口相比私有协议具有准入门槛低、易于推广的特点，符合泛在业务环境下能力汇聚与开放的需求．

转载请注明来自：http://www.zazhifabiao.com/lunwen/dzxx/rjkf/28121.html