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

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

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

  3. OTA的镜像页请求实现

  根据ZigBee OTA的规范,OTA客户端向OTA服务器请求镜像的方式有两种,分别是镜像块请求与镜像页请求。前者是基于二次握手机制,镜像块请求包含了已下载镜像的偏移量(File offset)与每次传输的镜像块大小等信息。当OTA服务器接收到该请求后,根据请求节点的短地址,镜像偏移量和镜像块大小等信息,通过串口向OTA应用控制台索取特定的镜像块。随后,OTA服务器回复的镜像块响应包含了该镜像块数据。当节点收到镜像块数据后,把块数据写到第二存储区,随即更新下载镜像的偏移量,并准备下一轮的请求。

  镜像块请求的优点是能够通过二次握手机制,确保每次传输的镜像块数据准确无误。但是大量的请求信息,无疑给整个网络的流量造成了严重的负担。再者,节点不停地发送请求命令,也加剧了自身的能源损耗。在外界干扰并不严重或点对点传输的应用场合,节点与服务器交换数据的过程并不会出现大量的丢包现象,基于块请求的OTA更新方式效率较低。于是需要设计出一种能够减轻网络流量,提高效率的更新手段。

  镜像块请求功能在大部分的ZigBee开发平台上(如TI的Z-Stack协议栈)已得到实现,但并没有提供镜像页请求功能。本文根据ZigBee OTA的规范,在Z-Stack协议栈上设计出镜像页请求的更新方式。页请求命令与块请求命令类似,在数据帧当中附加了镜像页大小(Page Size)与响应间隔(Response Spacing)信息。当OTA服务器收到一次页请求后,在一定时间间隔内,多次向节点发送块响应,免去了多次块请求。其中块响应的次数由镜像页大小决定,时间间隔由响应间隔设定。正因为请求命令的锐减,能够大大减轻整个网络流量的负担,并提高节点的传输更新效率。

  Z-Stack运行在一个OSAL操作系统上,OSAL是一种基于任务事件调度机制的操作系统。每个任务包含若干事件,每个事件对应一个事件号。当一个事件需要产生时,可以通过API函数设置相应的事件号,然后提交给操作系统调度触发。本文设计的镜像页请求功能正是基于这种机制。如图4所示,OTA服务器为每一个请求更新的节点分配一个事件号,并通过请求节点的短地址索引,设置特定的事件。进入事件后,OTA服务器通过串口向OTA应用控制台请求镜像数据块,并向节点发送镜像块数据。通过把事件添加到定时器链表,就能够以响应间隔为时间单位,循环发送镜像块数据,直到累计的发送镜像块大小等于节点的请求镜像页大小,从而完成一次镜像页请求的传输过程。

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

  Z-Stack协议栈有一个MAC定时器为操作系统提供计时。该定时器以每1ms为单位,更新系统的定时器事件链表。定时器事件链表如图5所示,链表的每一个结点记录了任务号(task_id),事件号(event_flag)与计时时间( timeout )和下一个结点地址(*next)。图中ZCL_OTA_MT_READn定义为每个请求节点对应的事件号,Response Spacing即为节点请求的响应间隔,把两者添加到链表当中。当计时时间减为0后,系统自动设定对应的事件号,从而使OTA服务器循环地向OTA应用控制台索取镜像块数据,并向节点发送镜像块响应。

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

  以下是OTA服务器处理镜像页请求的部分代码段:

  typedef struct

  {

  uint32 SeverfileOffset; //OTA服务器读取镜像的偏移量,与OTA客户端的同步

  afAddrType_t Psourceaddress; //OTA客户端短地址

  zclOTA_FileID_t FileID; //镜像信息,包括镜像类型,制造商ID与版本号

  uint16 ResponseTime; //响应间隔时间

  uint8 Length; //镜像块大小

  uint8 Count; //镜像页计数

  } zclOTA_Address_Index; //镜像页请求属性结构体

  zclOTA_Address_Index Address_index[]; //镜像页请求属性结构体数组

  if ( events & ZCL_OTA_MT_READn ) //处理OTA客户端镜像页请求事件

  {

  ZStatus_t status = ZFailure; //初始化状态值

  Address_index[n].Count--; //自减镜像页计数变量

  if(Address_index[n].SeverfileOffset >= Imagesize) //判断镜像偏移量是否超出镜像大小

  {

  return ( events ^ ZCL_OTA_MT_READn ); //如果超出直接退出事件处理

  }

  //OTA服务器根据OTA客户端的镜像页请求信息,向应用控制台索取镜像块数据

  Status = MT_OtaFileReadReq(&(Address_index[n].Psourceaddress), &(Address_index[n].FileID), Address_index[n].Length, Address_index[n].SeverfileOffset);

  if (status == ZSuccess) //假如索取成功,累加已请求的镜像偏移量

  {

  Address_index[n].SeverfileOffset += Address_index[n].Length;

  }

  if(Address_index[n].Count > 0) //判断累计的请求镜像块大小是否超出镜像页大小

  {

  //假如没超出,把该镜像页处理时间继续添加到定时器链表,等待下一轮的处理

  osal_start_timerEx(zclOTA_TaskID, ZCL_OTA_MT_READn,Address_index[n].ResponseTime);

  }

  //结束处理事件,并清除该事件号

  return ( events ^ ZCL_OTA_MT_READn );

  }

  4. 验证与分析

  4. 1功能验证

  为了验证OTA功能,在CC2530F256平台上搭建一个小型树状网络,并使用Packet Sniffer[13]对OTA更新时的节点进行抓包分析。如图6(a)所示,四个传感节点的当前固件并没有添加温度采集功能,所以温度显示为0;在新的固件中添加了温度采集函数,用于验证OTA更新成功。

  对于某些特定应用,需要节点更新固件后能够保持原来的网络拓扑结构。内部Flash的NV区能够保存节点的网络信息,只要在工程添加NV_INIT与NV_RESTORE预编译项,节点在掉电后还能恢复原来网络信息。

  对四个传感节点进行OTA更新。如图6(b)所示,OTA更新后,温度采集功能成功添加,而且传感节点的网络短地址没有发生变化,网络拓扑结构保持完整,验证了进行OTA镜像升级过程中,并不会对NV区进行擦除,有利于节点网络信息的恢复。

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

  在OTA更新过程中,应用层的数据帧格式如图7所示。OTA服务器被配置为路由器(0x06BC),对传感节点(0x0002)进行点对点更新。第一条短帧是子路由向OTA服务器发送Image Block Request,应用层载荷从第4字节开始记录了新镜像的制造商ID(0x5678),镜像类型(0x1234),版本号(0x00000002)和镜像块偏移量。最后1个字节记录了每次传送最大镜像块大小(OTA_MAX_MTU),默认为0x20,即为32字节。第二条长帧是OTA服务器发送的Image Block Response,载荷记录格式与前者类似,并在最大镜像块大小字节后面附上32字节镜像块信息,从而完成一个镜像块传输周期。

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

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

发表评论

0条评论,0人参与

请输入评论内容...

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

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

暂无评论

暂无评论

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

粤公网安备 44030502002758号