侵权投诉
订阅
纠错
加入自媒体

ZigBee空中下载技术研究及其优化设计

2014-12-15 15:06
默菲
关注

  摘要:无线传感网络是由大量体积小,供电资源有限,并配置一定计算能力和无线通讯能力的传感节点组成。对于传感网络系统,一定存在程序代码更新和维护的需求,但由于传感节点分散部署的特点,使得网络远程节点的程序升级变得异常困难。为此,空中下载(over the air, OTA)提供了一种有效的更新手段。本文首先介绍基于 ZigBee协议的OTA系统,并在CC2530F256 硬件平台作出验证。最后,在Z-Stack协议栈中,设计出一种镜像页请求的OTA更新方式,并通过实验测试,与原有的镜像块请求方式进行了比较分析。实验结果表明,镜像页请求方式可以大大减少网络的更新流量,从而提高节点的更新效率。

  0. 引言

  近年来,由于硬件成本的下降以及制造工艺的进步,无线传感网络技术逐步取得大规模商业应用,如医疗监控,智能电网和智能家居[1]。对于任何一个嵌入式计算机系统,都存在程序代码升级的需要。在无线传感网络的应用环境中,由于大量节点分散性部署,节点的回收工作变得异常困难,使传统的物理连接的程序更新手段不再适用。对此,一种有效的解决方案是OTA技术。

  空中下载技术起源于移动电话网络,能够通过移动通信网络(如GSM)对SIM卡数据进行远程管理与更新[2]。借鉴于移动通信网络,空中下载技术也能应用于无线传感网络。与网络层的路由协议[3]不同,代码分发协议[4]是支撑OTA的核心技术。前者关注的是如何迅速高效地中转网络中的数据信息,后者关注的是如何向各节点完整无误地传递更新代码[5]。目前,成熟的代码分发协议已经提出,典型的如基于TinyOS系统的Xnp[6]与Deluge[7],前者提出了单跳网络的更新方案,后者支持多跳网络更新功能,但都需要具体的硬件平台支持。

  本文移植并验证了一种基于ZigBee协议[8]的空中下载技术,其分发协议支持点对多传输更新功能,多跳网络的代码分发功能由路由协议支撑。在Z-Stack协议栈[9]下,仅仅支持镜像块请求功能,更新效率并不理想。针对此问题,设计出一种高效的镜像页请求功能,能够提高点对多的传输更新效率,并减少网络流量。

  1. OTA概述

  ZigBee协议规范使用了IEEE 802.15.4定义的物理层(PHY)和媒体介质访问层(MAC),并在此基础上定义了网络层(NWK)应用层(APL)。针对无线传感网络重编程技术的需求,ZigBee联盟在原有协议的框架上,提出了一种OTA规范[10],作为一个系统可选的功能模块。

  图1为OTA系统的结构示意图,整个系统主要由3部分构成:OTA应用控制台,OTA服务器,OTA客户端。其中OTA应用控制台是上位机管理软件,负责OTA镜像管理,网络节点信息陈列与发送更新命令;OTA服务器负责向远程节点无线发送升级镜像,并通过串口与上位机连接,向应用控制台汇报各节点更新进度信息等;OTA客户端是指远程网络中的待升级节点。

ZigBee空中下载技术研究及其优化设计

  根据代码的更新范围,分为整体代码更新与基于差异性的更新[11]。前者是把所有可执行的二进制代码打包成一个镜像分发给节点,后者是通过比较新旧镜像文件之间的差异,产生一个编辑脚本,然后把这个脚本分发到网络中的节点进行差异性更新。毫无疑问,前者需要传输的数据量较大,一般为上千字节级,增加了网络负担,但代码更新操作相对简单;后者发送的数据量虽少,但增加了更新过程的复杂度,对处理器产生更大的负担,带来较大的能源损耗。由于ZigBee协议对网络节点的低功耗标准有严格的要求,其OTA代码分发协议采用前者的镜像传输方式。

ZigBee空中下载技术研究及其优化设计

  服务器与客户端之间的数据交互过程如图2所示。首先OTA服务器通过单播或者广播方式向OTA客户端(节点)发送镜像公告(Image Notify),指示新镜像已经准备好。收到镜像提示信息后,节点就向OTA服务器发送查询下一个镜像请求(Query Next Image Request),此请求信息包含了当前运行固件的版本信息。收到该请求后,OTA服务器作出响应(Query Next Image Response)。随后,OTA客户端与OTA服务器通过二次握手机制,镜像块请求(Image Block Request)和镜像块响应(Image Block Response),完成整个镜像传输过程。当OTA客户端收到镜像块数据后,把块数据写到第二存储区(客户端当前运行的镜像保存在第一存储区)。完成下载后,节点将对下载后的镜像进行CRC校验。最后,当节点需要更新时,把新镜像从第二存储区复制到第一存储区,新固件开始运行,从而完成了整个升级过程。

  2. OTA系统设计

  本文的OTA系统基于TI公司的ZigBee SOC芯片CC2530F256[12]设计,包括硬件与软件的设计。其中硬件部分主要涉及CC2530 F256内部Flash存储空间分配方式与镜像存储方式的选择;软件部分介绍了OTA启动代码工作流程。

  2. 1硬件系统

  CC2530F256内部集成一个增强型8051单片机,拥有8KB SRAM和256KB内部flash存储器。内部flash主要用来保存程序代码和常量数据。由于传统8051 代码存储空间寻址范围只有64KB,CC2530把内部256KB flash分成8个bank,每一个bank大小是32KB,通过寄存器FMAP.MAP[2:0]选择不同的bank映射到代码存储空间,解决了寻址空间受限的问题。

  对于OTA客户端,启动代码位于bank0的0x0000到0x0800地址区域,大小为2KB。其余的254KB的flash空间,用来存储当前固件和其他信息。值得注意的是,0x0888~0x088B区域存放了CRC校验信息,0x088C~0x0897区域存放了PREAMBLE,即镜像大小,制造商ID,镜像类型和镜像版本号信息。另外,bank7最后的14KB空间(0x7C800~0x7FFFF)用作非易失性(None volatile, NV)变量区(12KB)和特定信息保留区(2KB)。

  OTA系统升级方案有两种,分别是片内flash升级和片外flash升级。片内flash的方案是把256KB的flash大小分成两半,前一半(第一存储区)提供给当前运行镜像存储,后一半(第二存储区)提供给新镜像存储;片外flash的方案是把片内flash作为第一存储区,外扩的flash作为第二存储区。考虑到一般程序固件大小都超过128KB,和以后程序功能升级的扩展性,本文采用片外flash的方案。采用的片外flash(M25PE20)容量为256KB,通过SPI总线与CC2530之间传输数据。

  2. 2软件系统

  对于基于任务事件轮询机制的Z-Stack工程,默认是没有添加OTA功能。如果节点需要开启OTA功能,首先需要烧写OTA的启动代码。当节点完成镜像接收之后,对新镜像进行CRC校验,并清空当前镜像的CRC信息,然后重启。当节点重启后,首先跳转到启动代。

ZigBee空中下载技术研究及其优化设计

  码的地址,开始执行如图3所示的工作流程。由于内部镜像的CRC信息被清空,所以被判断为不正确而执行下一步。由于为0的CRC信息标志着不需要被重新校验,故执行将新镜像复制到片内Flash的操作,并产生新镜像的CRC信息。然后,重新执行启动代码。新镜像启动时读取其CRC信息,再次判断后跳转到应用程序区,完成整个启动过程。

1  2  3  下一页>  
声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号