基于互联网服务器的海量ZigBee节点管理系统①

芦晨博

(沈阳工业大学 信息科学与工程学院,沈阳 110870)

引言

在基于Z-Stack 协议栈的ZigBee 网络中通过使用16 位短地址[1]在本地网络中标识设备和在网络中发送数据,当一个节点加入网络的时候将由它的父节点给它分配短地址[2].这个短地址的长度规定了在一个ZigBee 网络中最多能搭载65 535 个节点,而在实际应用中由于ZigBee 节点芯片的运算能力有限,加上载波侦听多路访问／冲突避免[3](Carrier Sense Multiple Access with Collision Detection,CSMA/CA)等原因很难达到上万节点的挂载.在使用全路由节点网络[4,5],更强性能的协调器或多信道通讯等手段时虽然可有效提高网络中的节点数量,仍然无法突破短地址带来的上限,同时又大大增加了系统复杂度.在物联网蓬勃发展的今天与万物皆可互联的理念下[6],搭建能够处理大量节点的网络结构意义重大.

本文通过在ZigBee 节点网络之上利用互联网服务器搭建外网结构,集中管理各个内网ZigBee 节点群,并提供自组网功能.根据实际业务需求进行节点网络的组建,服务端将集中管理所有节点数据并对外提供Web 服务.在服务端的架构设计上可采用分布式,搭建集群,负载均衡等多种应对高并发[7,8]的设计方式,使得系统性能与节点挂载能力获得极大提升.

1 整体设计

系统整体由终端节点,节点协调器,内网控制器,中央服务器,人机接口构成五层网络结构.

终端节点、协调器、内网控制器组成内网结构.其中ZigBee 终端节点可挂载各类传感器和控制设备与ZigBee 协调器之间通过利用Z-Stack 协议栈完成自组网与无线通讯功能.每个独立的ZigBee 网络都配有一台直接与外网相连并具有一定存储功能的内网控制器.协调器与内网控制器可通过串口相连或直接集成在一起.控制器接受中央服务器的指令信息来驱动ZigBee 协调器,并通过广播的方式向终端节点传递指令消息,同时将终端的状态信息同步至中央服务器.

中央服务器内维护着各个内网系统控制器的IP地址和与之相匹配的身份标识.整个系统中每一个终端节点拥有一个唯一的全局节点ID(GlobalID),服务器通过GlobalID 和控制器IP 地址可对指定节点发送控制信息.中央数据库内存储着所有节点的状态信息并可提供Web 服务供用户客户端访问.整体结构如图1.

2 内网结构设计

2.1 终端节点

任意一个内网结构中,每个终端节点在启动之前会被分配一个身份标识符(NodeID).启动设备后在ZStack 协议栈的帮助下会自动寻找当前网络内的协调器,若匹配成功则加入该网络.在完成自组网工作后节点进入正常工作状态.终端节点除自组网任务外仍需在Z-Stack 协议栈操作系统抽象层(Operating System Abstraction Layer,OSAL)[9]中注册和初始化两项基本任务.

图1 整体机构示意图

(1)状态信息定时发送任务：终端节点周期性的向网络内的协调器发送状态信息其目的是为了表明自身存活状态并可传递各类传感器信息.数据格式一般为：NodeID+状态信息.

(2)指令消息接受任务：系统中协调器以广播的形式传递消息,数据格式为：NodeID+操作码,当终端指令与指令消息中的NodeID 对比成功后执行操作码对应的自定义任务,对比失败则忽略消息.

2.2 协调器

系统中ZigBee 协调器除完成自组网任务外,仅作为消息的传递者.将内网控制器传来并将受到的终端节点状态信息传递给内网控制器.

2.3 内网控制器

内网控制器是连接ZigBee 网络与中央服务器的核心枢纽,用于解析服务端请求,向协调器发送指令信息和封装节点状态信息同步至中央服务器.控制器会被分配一个公网IP 地址供中央服务器查找.在本文的设计中控制器需至少包含四项基本任务：

(1)中央服务器消息监听任务(CenterMsgListener)：启动一个SocketService 监听指定端口,中央服务器会向该端口发送各类指令信息,调用MsgParser 解析指令消息,其中数据段的格式为GlobalID(全局节点ID)的指令消息原封不动通过广播方式发送出去.

(2)中央服务器消息发送任务(CenterMsgSender)：新建SocketClient 向中央服务器发送包括控制器心跳、注册信息、节点状态的更新、新节点入网与节点失活等多种消息.

(3)协调器消息监听任务(ZNodeMsgListener)：接收协调器收集到的终点节点状态信息.

(4)协调器消息发送任务(ZNodeSender)：向协调器发送正确格式的指令字符.在控制器初始化阶段还需加载4 张基本数据表.

表1 控制器初始化基本数据表

2.3.1 处理服务器控制信息

当控制器接收到中央服务器的指令消息时需依次执行以下任务：

(1)解析消息获取指令数据段,解析失败向服务器返回ERROR-指令消息非法.

(2)查询Global2Node 获取内网节点ID,获取失败时向服务端返回EXCEPTION-节点不存在或已下线.

(3)对照Command 表封装正确格式的指令信息.

(4)获取ZNodeSender 向协调器发送指令消息字符,若发送失败向服务端返ERROR (节点操作失败).

(5)向服务端返回SUCCESS.

(6)更新NodeStatus 表中的状态信息.

(7)在本地磁盘内新增操作记录与日志信息.

2.3.2 处理协调器节点消息

控制器接收到协调器节点心跳信息时需根据内容作出不同的处理,当某一节点的心跳消息第一次出现时需在本地缓存节点状态信息,为减轻服务器端的压力只有在节点状态发生实质上的变化时才会发送更新消息.具体处理流程如图2所示.

2.3.3 处理节点离线

Status 中记录着对应节点的上次心跳时间,控制器初始化完成后启动监听线程周期性的遍历NodeStatus表,根据当前时间戳查找已超时节点,封装超时节点信息向服务端发送节点下线消息,清除NodeStatus 中缓存的对应节点记录,更新本地数据库.

3 外网结构设计

3.1 中央服务器

中央服务器是外网结构的核心,其核心功能主要分为三部分：

(1)维护各个内网控制器的通讯地址与通讯方式,快速匹配目标节点发送控制信息.

(2)响应并处理控制器请求,存储所有节点状态信息,维护系统内数据的一致性.

(3)对外提供Web 服务,将对ZigBee 节点的操作抽象成具体业务功能.外网结构如图3所示.

对于客户端来说,所有被查询的节点数据均来自于中央数据库,在享受这种高效的,体验良好的查询服务时,需要重点关注数据实时性的问题.系统内影响实时性的主要因素来源于从节点状态发生变化到数据库更新所产生的时间差.

针对此问题在内网结构中可以选择提高心跳信息的采集频率、使用更高性能的网络模块、在终端节点上采用中断的方式提交更新数据或者可以在同一业务区域内搭建多个内网结构.更高的实时性必然需要付出更多的成本和性能.对于中央服务器而言并不需要过多的关心业务,最重要的是尽可能的提高处理并发的能力.除了在请求处理上采用合理的负载均衡策略外,值得一提的是在节点ID 字段的分配时可在其中加入业务地区与业务类型的标识字符,这种设计在存储时十分有利于做分库分表[10],在查询时也可根据ID 中的标识字符定位数据库的位置.性能提高十分明显.

图2 节点信息处理流程图

图3 外网结构示意图

当服务器接受到节点操作请求时,为保证节点操作的准确性与系统内数据的一致性,用户的请求与中央服务器对控制器的操作请求都应该是阻塞的,核心数据的事务[11]应包含整个过程.

3.2 控制器注册与组网机制

在控制器初始化阶段控制器需向中央服务器发送注册信息表明身份请求接入网络.数据段中至少包括：自身IP 地址,用于接受消息的端口号与通讯的使用密钥.

其中密钥为中央服务器与控制器之间约定的加密与解密字符,为保证通讯的安全每一次消息的传递都应使用密钥,出于对时效性与安全性的考虑还在加密字段中加入了时间戳,在加密与解密的两次结果中时间间隔过长也应视为异常信息.

当控制器第一次注册时(即服务器内没有该控制器记录)视为新入网控制器.中央服务器会为其分配一个ID 响应给控制器,同时在中央数据库生成连接记录,并将该控制器加入心跳监听序列中.

当注册完成后控制器陆续会将它所在内网中新加入的ZigBee 节点信息发送至服务器,此时消息数据段中包括控制器ID 节点GlobalID 和节点信息.在服务器将新增ZigBee 节点的数据同步完成后该网络内的节点即可正常使用.

顺利完成第一次注册后控制器会在本地持久化控制器ID,当控制器重新启动再次进行注册任务时会携带控制器ID 表明身份重新激活网络连接.当控制器各项信息需要更新时便可使用重新注册的方式.

3.3 控制器与中央服务器之间的心跳机制

控制器注册完成之后会周期性的向中央服务器发送心跳包,服务器会集中管理并监听所有ZigBee 网络的心跳[12].本文的设计中使用了redis[13,14]中SortedSet结构集中管理心跳记录,成员分数为最近一次心跳的时间戳.当集合中成员数量大于64 时SortedSet 同时使用了Hash 和Skiplist[15]两种设计实现,其范围查找操作复杂度一般为O(log(N)+M)(N为有序集的基数,M为被结果集的基数).使用范围查找在集合中成员分数小于当前时间戳与约定超时时间的差所产生的结果集即可认为是心跳已超时的连接.服务端将会对结果集内的控制器发送存活确认消息,当消息响应异常时可视为连接中断,更改控制器及属于该控制器网络中所有节点的连接状态并执行相应的离线异常处理机制.

3.4 人机接口设计思路

系统内针对用户的查询与控制操作都通过访问中央服务器所提供的Web 服务实现.用户可通过使用浏览器或手机app 等多种互联网手段向服务器发送请求,服务端最终会将用户的行为翻译成节点GlobalID 与操作码的形式.通过GlobalID 查询数据库,如果是控制信息将获取节点所在内网的IP 地址,再由服务端与指定的ZigBee 网络进行通讯.

4 简单测试系统的搭建

为验证系统可行性,利用有限的硬件资源搭建如下测试系统：

系统中央服务器采用阿里云轻量级应用服务器：1 核CPU、2 GB 内存、40 GB 固态硬盘、峰值带宽1 Mbps、操作系统为CentOS 7.3 版本、提供独立公网IP 与域名解析功能.在服务器内使用Redis 3.0 搭配MySQL 5.7 版本作为系统中央数据库.后端代码主要由Java 语言编写,所有针对处理用户http 请求的服务均使用了Tomcat 服务器.网站的入口使用Nginx 作为反向代理服务器用于匹配并分发不同类型的请求.

内网控制器由Java 语言编写,并只依赖于Java 虚拟机,便于移植.为验证存在多个内网控制器时系统的运行状态,使用VMware 启动10 台虚拟机作为内网控制器,运行环境为CentOS7.3,利用花生壳内网穿透、端口映射软件将10 台虚拟机与公网相连.个人电脑与协调器通过串口相连,为解决多个虚拟机无法同时访问一个串口的问题,编写脚本进行串口收发再与虚拟机进行通讯起到模拟相连的作用.虽然多个控制器是与同一个ZigBee 网络相连,但由于相互之间网络地址不同,数据也不同步,即可视为多个网络.

系统中协调器与终端均使用CC2530 芯片,协议栈版本为TI-Z-Stack 2007.网络内有一个协调器搭配37 枚终端,部分终端搭载了超声波传感器或温湿度传感器.

在整个测试过程中,系统能够自行处理任意ZigBee 节点层面和内网控制器层面的接入与离线情况,运行稳定鲁棒性强.通过访问中

央服务器可实时查询任意节点上传感器的测量值,针对不同内网之间实际相同节点的数据查询极少出现不同步状况.通过http 请求的方式对节点上LED 小灯的控制信息在当前测试环境下操作延迟一般在3 秒内即可完成响应,当对于任意一个网络内的节点下达控制信息后,其余9 个网络中的节点信息均能在不超过两个节点心跳的时间内同步至中央服务器.

5 结束语

本文提出一种通过搭建互联网服务器的方式来集中管理多个ZigBee 网络的设计方案.所有节点的数据集中存储便于访问,同时可对系统内任意节点实现精准控制与状态信息的获取.各个ZigBee 网络之间的设计不存在耦合,在不同业务背景下应用时不需要更改底层实现,系统扩展性强.接下来的工作中需重点关注ZigBee 网络中对控制指令执行的可靠性问题,完善各类异常处理机制.并针对系统各个模块的性能进行更多的测试工作.