基于6LOWPAN的智能家居控制系统设计_第1页
基于6LOWPAN的智能家居控制系统设计_第2页
基于6LOWPAN的智能家居控制系统设计_第3页
基于6LOWPAN的智能家居控制系统设计_第4页
基于6LOWPAN的智能家居控制系统设计_第5页
已阅读5页,还剩74页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

毕业设计基于6LOWPAN的智能家居控制系统设计学生姓名学号专业班级指导教师学院答辩日期基于6LOWPAN的智能家居控制系统设计TheDesignofControlSystemBasedon6LOWPANforSmartHome绪论随着物联网技术的日益成熟,物联网技术在民生、农业、经济等方面正在发挥不容忽视的作用。在日常生活中,已经有许多物联网技术带来的细微变化正在人们的身边发生。现在发展相对比较成熟的,就是汽车移动物联网(车联网),通过在车辆上安装各式各样的传感器,如红外感应器、射频识别、全球定位系统等信息传感设备,然后通过无线通信技术,将采集的各种信息上传到互联网上,进而实现车辆的驾驶人员感应、识别、定位等功能,便于统一监控和管理。例如现在很多地图导航应用可以显示实时路况,就是通过安装在出租车上的传感器实现的,通过分析在该路段所有出租车的行车状况,以此给出路况参照。在物联网领域另一个更有发展潜质的就是智能家居,现在智能家居在人们家庭住宅的应用还很少,但是住宅是每个人家的基础,一个人一天至少有一半以上的时间在家中度过,如果能够在生活起居各个方面方便人们的居家生活,智能家居必将具有更大的发展空间。国家也很重视物联网及其在智能家居行业的发展与应用,民生才是一个国家的根本,如果一个国家人民的生活水平、生活质量提高了,才能真正意味着这个国家的工业化和信息化水平的提高,在这个大背景下,由国家工业和信息化部在即将迎来2012之时提出了《物联网“十二五”发展规划》,该规划中明确将智能家居作为提升民生水平的物联网应用作为重点发展和照顾对象,加以大力支持并力求在未来内通过高新技术手段和创新技术手段近一步提高人民的生活。尽管在物联网技术的推动下智能家居行业呈现良好的发展态势,但是这个新兴行业在国内经过大概10年的发展,非但没有进入繁荣期,市场反而一直处于低迷期,基本上没有取得突破性的发展。究其原因,主要还是一下3点,行业标准不统一、系统价格不亲民、产品不够人性化。很多问题显而易见,但是又得不到太好的解决办法。1)智能家居行业还比较混乱,行业的各个厂家标准和协议不统一,各自为营,行业陷入无序发展,使得彼此之间的产品无法兼容。如果用户的智能家居系统出现问题,需更换配件时,只能选择同品牌提供的产品,否则整个系统就得拆掉。这不仅造成巨大的浪费,还在很大程度限制了智能家居的发展。2)目前智能家居系统的产品价格偏高,只有部分人群能够消费起,配备智能家居系统的楼盘大多更是天价级别的楼盘。无法进入普通百姓家也就意味着无法将智能家居推广,如果能够做到像现在智能手机的普及程度,才认为这个世界进入了智能家居时代。3)智能家居不够人性化,用户体验不够好,作为一款新兴的技术产品,如果操作系统缺乏人性化设计,最大优化用户体验,会使得用户望而生畏。智能家居的使用场合一般是家庭环境,家中如果有老人、小孩,就需要系统能够实现通过简单的操作,达到快捷、便利的效果。但遗憾的是,现在虽然很多智能家居产品功能很多,但是在人性化设计、用户体验方面不完善,使得智能家居系统陷入了一种中看不中用的地步。针对智能家居领域出现的各种问题,如何协调解决好这些问题,成为带领智能家居行业走出现在这个窘境、实现大步发展的关键所在。因此,只有选择一条符合国情、属于中国发展模式的道路,才能改变目前的状态。因此要想让智能家居的理念深入人心,首先得让人们切实的体验到智能家居所带来的便捷生活,让越来越多的人都想要一套智能家居系统。曾经有人做过一个行业的调查,几乎所有人都有使用智能家居的美好愿望,但是在问及是否会安装智能家居系统时,大多数人总会以价格太高或房子已装修完为由,拒绝安装,其实在他们心底,真正的原因是还没有形成这样的理念——“智能家居跟电视、冰箱、洗衣机和手机是一样一样的,都属于生活必需品”。基于以上3点考虑,选择一个适合智能家居系统的标准协议,降低系统产品价格,最大优化产品用户体验,成为一条必经之路。目前智能家居系统大多数是使用Zigbee技术作为数据传输协议。Zigbee是为技术人员熟知的基于IEEE802.15.4标准的低功耗个域网协议,该协议作为无线传感器网络的主流协议在智能家居领域得到广泛应用。早期时候,智能家居系统通过增加GSM模块发送、接收短信来实现与用户的远程交互,现如今多数智能家居系统都能接入互联网,但是基本都是建立在IPv4网络基础上,实现与用户的远程交互。这样做的局限性很明显:IPv4的32位地址总容量约为43亿个,然而在2012年之时IP地址就已经分配完毕,因为IPv4在设计之初只考虑到为全球的主机分配IP地址,如果要为全球各家各户的家电设备、监测传感器分配一个唯一IP地址,几乎是不可能的,即不可能实现IPanywhere。随着技术的发展,IPv6的提出很好地解决了地址资源枯竭的问题,有人曾经做过一个很贴切的对比来形容IPv6地址的丰富:“IPv6的地址数量,比地球所有沙子数量的总和还要来得多得多”。IPv6的提出使IPanywhere成为一种可能,这似乎也成为了解决智能家居所面临瓶颈的关键所在,但是IPv6的许多其他功能对于智能家居系统来说太过复杂、或者冗余,而且智能家居系统需要在嵌入式设备上实现,也就是说在硬件条件受限的情况下,如何实现嵌入式设备的IPv6化,便是主要问题。IETF(InternetEngineeringTaskForce)为了解决这个燃眉之急,在2004的年末成立了6LOWPAN工作组,该小组的主要任务就是解决上面提到过的“如何在IEEE802.15.4网络的基础上进行并实现IPv6数据报文的传输”的问题。到目前为止,该小组已经进行许多研究并形成草案予以发布,例如在草案RFC4944中就提出了6LOWPAN适配层的概念来解决一些关键性的技术问题。本设计将现有的6LOWPAN技术应用到智能家居系统上,能有效解决IP地址枯竭的问题。在现阶段一个基于6LOWPAN技术的智能家居系统极为少见,能够为行业提供一个应用范例。另一方面,为了降低成本,需要最大限度的把用户自有的设备终端纳入智能家居系统,如智能手机、路由器等。并且使用市面上已经成熟的嵌入式设备、无线传感器网络节点以及各式传感器来开发智能家居系统。此外,在用户住宅中安装智能家居系统时,应充分考虑用户家庭的布线情况,在尽可能减少二次装修的前提下,完成智能家居系统的安装。最后,近年来,随着B/S结构的兴起,即Browser/Server(浏览器/服务器)网络结构模式,WEB浏览器成为客户端最主要的应用软件。相比对C/S结构,即Client/Server(客户端/服务器)网络结构模式,B/S最大的优点就是,访问互联网上任何数据,如文本、图像、声音、视频等,都可以通过浏览器来完成,而不需要另外安装软件。在对当前行业背景进行上述分析后,本设计考虑遵照6LOWPAN协议标准,拟充分应用嵌入式硬件和客户端来进行设计,并实现一种采用B/S结构的智能家居系统,这样可以分别对应解决协议不规范、系统成本高昂及用户体验不友好等问题。但是由于技术水平所限,本设计只是在Contiki操作系统下的Cooja模拟器上实现了由RPL路由协议下的传感器网络的组网并实现远程控制。

6LOWPAN协议6LOWPAN技术背景6LOWPAN是一种基于IPv6的低速无线个域网标准,即IPv6overIEEE802.15.4。将IP协议引入无线通信网络一直被认为是不现实的(不是完全不可能)。迄今为止,无线网只采用专用协议,因为IP协议对内存和带宽要求较高,要降低它的运行环境要求以适应微控制器及低功率无线连接很困难。基于IEEE802.15.4实现IPv6通信的IETF6LOWPAN草案标准的发布有望改变这一局面。6LOWPAN所具有的低功率运行的潜力使它很适合应用在从手持机到仪器的设备中,而其对AES-128加密的内置支持为强健的认证和安全性打下了基础。IEEE802.15.4标准设计用于开发可以靠电池运行1到5年的紧凑型低功率廉价嵌入式设备(如传感器)。该标准使用工作在2.4GHz频段的无线电收发器传送信息,使用的频带与Wi-Fi相同,但其射频发射功率大约只有Wi-Fi的1%。这限制了IEEE802.15.4设备的传输距离,因此,多台设备必须一起工作才能在更长的距离上逐跳传送信息和绕过障碍物。IETF6LOWPAN工作组的任务是定义在如何利用IEEE802.15.4链路支持基于IP的通信的同时,遵守开放标准以及保证与其他IP设备的互操作性。这样做将消除对多种复杂网关(每种网关对应一种本地802.15.4协议)以及专用适配器和网关专有安全与管理程序的需要。然而,利用IP并不是件容易的事情:IP的地址和包头很大,传送的数据可能过于庞大而无法容纳在很小的IEEE802.15.4数据包中。6LOWPAN工作组面临的技术挑战是发明一种将IP包头压缩到只传送必要内容的小数据包中的方法。他们的答案是“Payasyougo”式的包头压缩方法。这些方法去除IP包头中的冗余或不必要的网络级信息。IP包头在接收时从链路级802.15.4包头的相关域中得到这些网络级信息。最简单的使用情况是一台与邻近802.15.4设备通信的802.15.4设备将非常高效率地得到处理。整个40字节IPv6包头被缩减为1个包头压缩字节(HC1)和1字节的“剩余跳数”。因为源和目的IP地址可以由链路级64位唯一ID(EUI-64)或802.15.4中使用的16位短地址生成。8字节用户数据报协议传输包头被压缩为4字节。随着通信任务变得更加复杂,6LOWPAN也相应调整。为了与嵌入式网络之外的设备通信,6LOWPAN增加了更大的IP地址。当交换的数据量小到可以放到基本包中时,可以在没有开销的情况下打包传送。对于大型传输,6LOWPAN增加分段包头来跟踪信息如何被拆分到不同段中。如果单一跳802.15.4就可以将包传送到目的地,数据包可以在不增加开销地情况下传送。多跳则需要加入网状路由(mesh-routing)包头。IETF6LOWPAN取得的突破是得到一种非常紧凑、高效的IP实现,消除了以前造成各种专门标准和专有协议的因素。这在工业协议(BACNet、LonWorks、通用工业协议和监控与数据采集)领域具有特别的价值。这些协议最初开发是为了提供特殊的行业特有的总线和链路(从控制器区域网总线到AC电源线)上的互操作性。几年前,这些协议的开发人员开发IP选择是为了实现利用以太网等“现代”技术。6LOWPAN的出现使这些老协议把它们的IP选择扩展到新的链路(如802.15.4)。因此,自然而然地可与专为802.15.4设计的新协议(如ZigBee和ISA100.11a)互操作。受益于此,各类低功率无线设备能够加入IP家庭中,与Wi-Fi、以太网以及其他类型的设备“称兄道弟”。随着IPv4地址的耗尽,IPv6是大势所趋。物联网技术的发展,将进一步推动IPv6的部署与应用。IETF6LOWPAN技术具有无线低功耗、自组织网络的特点,是物联网感知层、无线传感器网络的重要技术,ZigBee新一代智能电网标准中SEP2.0已经采用6LOWPAN技术,随着美国智能电网的部署,6LOWPAN将成为事实标准,全面替代ZigBee标准。6LOWPAN技术优势普及性:IP网络应用广泛,作为下一代互联网核心技术的IPv6,也在加速其普及的步伐,在低速无线个域网中使用IPv6更易于被接受。适用性:IP网络协议栈架构受到广泛的认可,低速无线个域网完全可以基于此架构进行简单、有效地开发。更多地址空间:IPv6应用于低速无线个域网时,最大亮点就是庞大的地址空间。这恰恰满足了部署大规模、高密度低速无线个域网设备的需要。支持无状态自动地址配置:IPv6中当节点启动时,可以自动读取MAC地址,并根据相关规则配置好所需的IPv6地址。这个特性对传感器网络来说,非常具有吸引力,因为在大多数情况下,不可能对传感器节点配置用户界面,节点必须具备自动配置功能。易接入:低速无线个域网使用IPv6技术,更易于接入其他基于IP技术的网络及下一代互联网,使其可以充分利用IP网络的技术进行发展。易开发:目前基于IPv6的许多技术已比较成熟,并被广泛接受,针对低速无线个域网的特性对这些技术进行适当的精简和取舍,可以简化协议开发的过程。6LOWPAN关键技术分析对于IPv6和IEEE805.15.4结合的关键技术,6LOWPAN工作组进行了积极的研究与讨论,目前在IEEE802.15.4上实现传输IPv6数据包的关键技术如下:1)IPv6和IEEE802.15.4的协调。IEEE802.15.4标准定义的最大帧长度是127字节.MAC头部最大长度为25字节,剩余的MAC载荷最大长度为102字节。如果使用安全模式,不同的安全算法占用不同的字节数,比如AES-CCM-128需要21字节,AES-CCM-64需要13字节,而AES-CCM-32需要8字节。这样留给MAC载荷最少只有81个字节。而在IPv6中。MAC载荷最大为1280字节。IEEE802.15.4帧不能封装完整的IPv6数据包。因此,要协调二者之间的关系,就要在网络层与MAC层之间引入适配层,用来完成分片和重组的功能。2)地址配置和地址管理。IPv6支持无状态地址自动配置,相对于有状态自动配置的来说,配置所需开销比较小,这正适合LR-WPAN设备特点。同时,由于LR-WPAN设备可能大量、密集地分布在人员比较难以到达的地方,实现无状态地址自动配置则更加重要。3)网络管理。网络管理技术对LR-WPAN网络很关键。由于网络规模大,而一些设备的分布地点又是人员所不能到达的,因此LR-WPAN网络应该具有自愈能力,要求LR-WPAN的网络管理技术能够在很低的开销下管理高度密集分布的设备。由于在IEEE802.15.4上转发IPv6数据提倡尽量使用已有的协议,而简单网络管理协议(SNMP)又为lP网络提供了一套很好的网络管理框架和实现方法,因此,6LOWPAN倾向于在LR-WPAN上使用SNMPv3进行网络管理。但是,由于SNMP的初衷是管理基于IP的互联网,要想将其应用到硬件资源受限的LR-WPAN网络中。仍需要进一步调研和改进。例如:限制数据类型、简化基本的编码规则等。4)安全问题。由于使用安全机制需要额外的处理和带宽资源,并不适合LR-WPAN设备,而IEEE802.15.4在链路层提供的AES安全机制又相对宽松,有待进一步加强,因此寻找一种适合LR-WPAN的安全机制就成为6LOWPAN研究的关键问题之一。作为当今信息领域新的研究热点,6LOWPAN还有非常多的关键技术有待发现和研究,比如:服务发现技术、设备发现技术、应用编程接口技术、数据融合技术等。6LOWPAN技术概述为了实现屏蔽底层硬件对IPv6网络层的限制,在他们之间加入了适配层,同时也实现了IPv6网络层与IEEE802.15.4MAC层之间的连接通信。在6LOWPAN的技术中最重要的就是适配层的技术,它使整个协议栈有序的工作。适配层报文格式6LOWPAN网络有报文长度小、带宽低、功耗低等的原因,为了缩短报文的长度,适配层帧头部采用两种格式,即分片(用来传输数据部分小于MAC层最大传输单元MTU(102字节)的报文)以及不分片(用来传输数据部分大于MAC层MTU的报文)的格式。当在IEEE802.15.4链路上传输IPv6报文时,IPv6报文被封装在这两种不同格式的适配层报文中,即在适配层头部的后边跟随的是IPV6报文作为适配层的负载。特殊地,如果把“M”或“B”bit位置为1时,MD或Broadcast字段会首先出现在适配层头部的后面,出现在这两个字段之后的就是IPv6的数据报文。不分片的报文格式:图2.1不分片的报文格式其各个字段的含义如下:LF:(LinkFragment)链路分片。为2bit,在不分片格式中该位为00。Prot-type:协议类型。为8bit,表示在报文头部的报文类型。M:(MeshDelivery)字段标志位。为1bit,如果该位置为1,则适配层头部后为“MeshDelivery”字段。B:(Broadcast)为1bit,如果该位置为1,则适配层头部后为“Broadcast”字段。rsv:(reservation)保留字段,全置为0。分片报文格式若一个报文的长度超过适配层传输的最大长度,考虑到节点存储以及能量的有限需要对报文进行分片。图2.2不分片的格式其各个字段的含义如下:LF:(LinkFragment)链路分片。为2bit,在分片格式中该字段不为0。有三种表示格式分别是:01表示第一分片,10表示最后的分片,11表示中间分片。Prot-type:协议类型。为8bit,表示在报文头部的报文类型。只在第一分片中出现。M:(MeshDelivery)字段标志位。为1bit,如果该位置为1,则适配层头部后为“MeshDelivery”字段。B:(Broadcast)为1bit,如果该位置为1,则适配层头部后为“Broadcast”字段。rsv:(reservation)保留字段,全置为0。Datagram-size:负载报文长度。为11bit,支持的最大长度为2048字节。能满足IPv6报文在IEEE802.15.4上传输1280字节MTU的要求。Datagram-tag:分片标识符。为9bit,所有同一报文的该标识都相同。fragment-offset:报文分片偏移。为8bit,改字段在第二分片及后继分片中出现,表示后继的分片与报文头部的偏移。分片与重组IPv6规定的链路层的MTU为1280个字节,但适配层并不支持这个MTU的要求,于是协议需要对链路层的报文进行分片与重组。因此,适配层需要通过对IP报文进行分片和重组来传输超过IEEE802.15.4MAC层最大帧长(127字节)的数据报文。将链路层的数据包分割成多个链路层帧,以适应IPv6最小MTU的要求,然后将分片的报文再进行重组继续传输。1分片当上层为适配层下传一个超过最大payload长度的报文时,适配层就对该IP报文进行分片传送。适配层进行分片的判断依据是:负载报文长度、不分片头部长度与MeshDelivery(或Broadcast)字段长度之和大于IEEE802.15.4MAC层的最大payload长度时需要分片。对分片的具体流程如下图所示:图2.3分片流程在第一分片中,01就表示第一分片,Prot-type标识上层协议为IPv6,且没有fragment_offset字段。在后继的分片中,分片头部设为11或10,表示中间分片跟最后分片。fragment_offset字段被设为当前的报文分片相对于原负载报文起始字节的偏移。对于Datagram-tag字段,每发完一个分片分组该字段就加1,直到增到511后又转为0继续增加到分片全部发送完。2重组当适配层接收到一个分片后,就根据源MAC地址跟分片头部的Datagram-tag字段来判断该分片属于哪个负载报文。重组的过程如下图所示:图2.4不分片报文流程若适配层第一次收到一个负载报文的分片,就将该被分片的源MAC地址和datagram_tag字段记下来方便以后供重组使用。如果该报文的其它分片已经收到,就依据当前分片帧的fragment_offset字段进行重组。若发现收到的是一个重复但不重叠的分片,应该使用新收到的分片进行替换。若本分片和前面的分片有重叠,则应该丢弃当前分片。以此来简化处理。在成功收到所有分片后,按根据分片的offset值进行重组,并将重组好的原始负载报文交给上层。并且还需要删除开始记录的源MAC地址和datagram_tag字段的信息。重组一个分片需要一个重组队列来维护已收到的分片等信息。另一方面,节点需要在收到第一分片后设置一个重组定时器来避免长时间未到的分片,定时时间设为15s,当超过该指定的时间后将删除队列中接收到的所有分片以及相关的信息,认为是错误的信息。寻址和自动配置IEEE802.15.4协议对物理层和MAC层的功能特性做出了详细的描述。这个协议的物理层规定了工作频段的范围、调制的方式、传输速率等。而MAC层提供了各种不同功能的通信原语来进行信道扫描和网络维护。但是从另一方面来看,MAC层并没有调用原语来形成网络拓扑结构和对这些拓扑结构进行维护的功能,因此维护拓扑结构的工作将由适配层来进行。6LOWPAN中的每个节点使用EUI-64标准作为地址标识符,但是大多数的6LOWPAN网络节点的存储、能量等非常有限,并且节点的数量也比较大,如果采用64-bits的地址可能会占用大量的存储空间,而且可能使报文载荷增加。因此,在适配层采用动态16-bits的短地址来标识网络中的每一个节点应该是更加适合的方案。报头压缩在没有校验等功能的前提下,IEEE802.15.4协议的MAC层提供的最大载荷(payload)是102个字节,IPv6规定的报文的头部占40个字节,再加上适配层和传输层等的头部,最后只剩下50个字节的空间用于传送数据。为了使IPv6数据满足IEEE802.15.4传输的最大传输单元MTU的要求,一方面可以通过分片和重组机制来传输过长的IPv6报文,另一方面需要对IPv6的报文进行压缩,从而减少冗余和提高数据传输的效率并且节省节点的能量。为了实现压缩,需要将表征头部压缩的编码字段增加在适配层的报文后边,这个字段将指出IPv6的那些字段被压缩了,除了对IPv6的头部字段压缩外,还可以对上层协议如UDP、TCP和ICMPv6的头部进行进一步的压缩。目前适配层只支持3种方式的压缩:用于IPv6头部压缩的LoWPAN_HC1格式;用于UDP头部压缩的HC_UDP格式,用于ICMPv6压缩的HC_ICMP格式。网络管理跟安全问题网络管理是一个很重要的一部分。由于网络中节点数量比较庞大,有些节点被部署到了网络维护人员不能达到的地方。因此要求部署在网络中的节点有自愈功能,在很低的开销下,网络管理技术能够管理分布高度密集的节点。6LOWPAN使用SNMPv3来进行网络的管理和维护。安全管理需要消耗额外的带宽资源。6LOWPAN使用由IEEE802.15.4提供的强大的AES-128的安全机制。虽然网络层的安全机制如IPsec和安全邻居变得越来越成熟,但是他们在6LOWPAN上能否可行仍然被质疑。

RPL路由协议RPL路由协议制定背景低功耗有损网络路由协议(RPL)是IETF的ROLL(RoutingOverLowpowerandLossynetworks)工作组,专门针对低功耗有损网络LLN(LowpowerandLossynetwork)新提出来的路由协议。低功耗有损网络是由功率、存储空间、处理能力等资源受限的嵌入式设备所组成的网络。它们可以通过多种链路连接,比如IEEE802.15.4、蓝牙、低功率Wi-Fi,甚至低功耗电力线通信(PLC)等等。ROLL将LLN网络的应用主要划分为四个领域:城市网络(包括智能电网应用)、建筑自动化、工业自动化以及家庭自动化,并且分别制定了针对四个应用领域的路由需求。由于LLN的独特性,传统的IP路由协议,比如OSPF、IS-IS、AODV、OLSR,无法满足其独特的路由需求,因此ROLL工作组制定了RPL协议,其协议标准RFC6550发布于2012年3月。RPL协议工作原理RPL路由协议是一个基于IPv6的距离矢量路由协议。它通过一个目标函数(ObjectiveFunction)和一些路由代价及路由约束建立一个目标导向的有向无环图DODAG(DestinationOrientedDirectedAcyclicGraph)。每个DODAG中的节点(根节点除外)会选择一个父节点作为沿着DODAG向上的默认路由。目标函数通过路由代价和约束来选择一条最优的路径。一个节点上可以有好多种不同的目标函数,因为同一个节点可以部署到不同的环境中去。有的应用环境要求用期望传输次数ETX(ExpectedTransmissions)作为路由代价,有的应用环境需要用延迟作为路由代价。当一个RPL节点获得一个IPv6地址后(通过DHCPv6动态获得或者静态指定),会通过和周围的节点交换3种ICMPv6消息(DIS,DIO和DAO)以选择自己父节点来加入一个目标导向的有向无环图。RPL路由协议支持点对点(point-To-point)、多点到点(multipoint-To-point)和点到多点(point-To-mutipoint)3种数据流动方式。RPL路由协议可以工作在两种不同的模式下:Non-StoringMode和StoringMode。在多点到点的流动方式中,Non-StoringMode和Storing模式中的节点都将父节点作为默认的下一跳路由,通过父节点转发数据到根节点。在点到多点方式中,Non-StoringMode只有根节点存有到下面节点的路由表,所以根节点会根据路由表构建到其余节点的源路由,而在StoringMode中除了根节点,其余节点也会存有路由表,所以根节点只会决定达到目的节点的下一跳地址,而不会构建一个源路由。在点到点流动方式中,Non-StoringMode会将数据先发送到源节点和目的节点共同的父节点,然后通过父节点将数据转发到目的节点。但是在StoringMode中会先将数据发送到根节点,然后通过根节点将数据发送到目的节点。RPL路由协议的拓扑结构图3.1DODAGVersionNumber低功耗易丢失网络,如无线网络,通常都没有一个预先定义好的拓扑结构,所以RPL路由协议需要发现连接,然后建立和维护拓扑结构。RPL路由协议通过4个值来建立和维护一个拓扑结构:RPLInstanceID、DODAGID、DODAGVersionNumber和Rank。具体细节如下图3.1DODAGVersionNumber1)RPLInstanceID:一个RPLInstanceID指定了一个或者几个DODAG。RPLInstanceID相同的节点使用相同的目标函数。然后是DODAGID,一个RPLInstance中有一个或者多个DODAG,每个DODAG有一个唯一的DODAGID。DODAGID的范围是一个RPLInstance。一个RPLInstanceID和一个DODAGID唯一的确定了一个DODAG。如图3.1中整个图为一个RPLInstance,RPLInstanceID为1。这个RPLInstance中有3个DODAG,DODAGID分别为1,2,3。RPLInstanceID=1和DODAGID=1就唯一地代表最左边的一个DODAG。图3.1中所标注的节点为DODAG根节点,DODAG根节点通过骨干网连接到路由器,然后再由路由器连接到传统的有线网络中去。图3.2DODAGVersionNumber2)DODAGVersionNumber:节点通常会因为自身的原因(如节点电池耗尽)或者环境原因而失去作用,结果导致DODAG的拓扑结构发生变化。因此路由协议必须维护DODAG的拓扑。RPL路由协议通过DODAGVersionNumber来定义不同DODAG的拓扑版本,当DODAG因为某种原因重新建立的时候,变成另外一个拓扑版本的时候,DODAGVersionNumber会加1。如图3.2,左边DODAG的版本号DODAGVersionNumber为N,当拓扑结构发生变化的时候,DODAG的版本号DODAGVersionNumber图3.2DODAGVersionNumber图3.3DODAGRank值3)节点的Rank值(图3.3)。Rank值的作用范围是一个DODAGVersionNumber当DODAGVersionNumber变化的时候,节点会重新计算Rank值。Rank值的大小代表了该节点距离根节点的距离,Rank值越小说明距根节点越近。DODAG根节点的Rank值为0,父节点的Rank值大于子节点的Rank值。Rank值可以用来避免路由回环和进行路由回环检测。一个节点Rank值由目标函数来计算。但值得注意的是Rank值不是一个路径代价,尽管Rank图3.3DODAGRank值RPL路由协议的建立过程运行RPL路由协议的节点之间通过交换DIO、DIS和DAO3种ICMPv6控制消息来建立拓扑和路由。整个过程分成两个过程。第一个过程是拓扑结构的建立和向上路由的建立,第二个过程是向下路由的建立。在建立向下路由的时候存在两种模式:StoringMode和Non-StoringMode。下面以图3.4所示的网络节点进行说明:1)拓扑建立和向上路由的建立:在最开始的时候,一些节点会被指定为DODAG根节点。当根节点工作后会向周围节点发送DIO消息。DIO消息中包含RPLInstanceID、DODAGVersionNumber、DODAGID、根节点Rank值、RPL路由协议工作的模式、DODAG的配置信息、路由代价以及通过根节点可以达到的地址等。因为一个RPLInstance中可能有好几个根节点,所以一个节点可能接收到多个根节点发送过来的DIO,这个时候节点会根据DIO中的路由代价信息使用目标函数选择自己的父节点,然后计算出节点自己的Rank值。然后该节点修改DIO中的路由代价和Rank值信息后向自己周围的节点发送DIO数据包。同理其余的节点可能会同时接收到好多节点给它发送的DIO,接着节点用DIO数据包中包含的路由代价信息使用目标函数从发送DIO的众多节点中选择一个节点作为自己的父节点,然后节点修改路由代价、Rank值等后再向它周围的节点发送DIO。这样所有节点都知道自己的父节点了,DODAG中的节点会将父节点作为路由时默认的下一跳节点,因此当DODAG中的节点向上发送数据的时候,就将数据包发送给父节点,然后通过父节点转发数据。如图3.4所示,第一个图为最开始的时候,节点0和节点1为根节点。节点2和节点3在节点0的通信范围内,节点3和节点4在节点1的通信范围内。第二个图,根节点开始向周围的节点发送DIO。节点2收到节点1的DIO,节点3同时收到节点0和节点1的DIO,节点4收到节点1的DIO。显然节点2和节点4分别选择了节点0和节点1作为自己的父节点,因为它们只收到了一个DIO。节点3通过目标函数计算选择了节点0作为自己的父节点。此时RPLInstance的状态就到了第三个图,节点2、节点3和节点4修改路由代价及Rank值能信息后再向自己的周围节点转发DIO,如图所示节点2给节点5和节点6发送了DIO,节点3和节点4都给节点6发送了DIO。最后节点5将节点2当作父节点,而节点6通过目标函数选择了节点4作为了父节点。到此时整个拓扑结构都建立起来了。当节点5要向节点0发送数据的时候,会将数据默认发给其父节点2,然后通过节点2转发给节点0。但是此时如果节点0要给节点5发送数据,节点0还不知道发送的路径。因为此时图3.4路由协议建立过程描述图3.4路由协议建立过程描述2)向下路由的建立:向下路由的建立有两种模式:StoringMode和Non-StoringMode。在StoringMode中所有节点上都会保存有向下的路由表,而在Non-StoringMode模式中只有根节点保存向下的路由表。在StoringMode下,一个节点收到DIO消息选择好父节点后,会向父节点发送DAO。DAO消息中包含了通过该节点可以达到的地址或者地址前缀信息。当父节点收到DAO后会处理DAO消息中的地址前缀,然后在路由表中加入相应的路由项。当父节点做完这些后就会向它的父节点发送DAO数据包。如此重复直到整个向下的路由建立起来。在Non-StoringMode下,一个节点收到DIO消息后不是向父节点发送DAO,而是向DODAG根节点发送DAO。当然必须要通过父节点转发。当根节点收到所有节点发送过来的DAO消息后,就会建立到所有节点的路由表。当根节点要向下面的节点发送数据包的时候,根节点根据路由表构建源路由。

Contiki操作系统Contiki操作系统简介Contiki是一个开源的、高度可移植的多任务操作系统,适用于互联网嵌入式系统和无线传感器网络,由瑞典计算机科学学院(SwedishInstituteofComputerScience)的AdamDunkels和他的团队开发。Contiki完全采用C语言开发,可移植性非常好,对硬件的要求极低,能够运行在各种类型的微处理器及电脑上,目前已经移植到8051单片机、MSP430、AVR、ARM、PC机等硬件平台上。Contiki适用于存储器资源十分受限的嵌入式单片机系统,典型的配置下contiki只占用约2Kbytes的RAM以及40Kbytes的Flash存储器。Contiki是开源的操作系统,适用于BSD协议,即可以任意修改和发布,无需任何版权费用,因此已经应用在许多项目中。Contiki操作系统是基于事件驱动(Event-driven)内核的操作系统,在此内核上,应用程序可以在运行时动态加载,非常灵活。在事件驱动内核基础上,contiki实现了一种轻量级的名为protothread的线程模型,来实现线性的、类似于线程的编程风格。该模型类似于Linux和windows中线程的概念,多个线程共享同一个任务栈,从而减少RAM占用。Contiki还提供一种可选的任务抢占机制、基于事件和消息传递的进程间通信机制。Contiki中还包括一个可选的GUI子系统,可以提供对本地串口终端、基于VNC的网络化虚拟显示或者Telnet的图形化支持。Contiki系统内部集成了两种类型的无线传感器网络协议栈:uIP和Rime。uIP是一个小型的符合RFC规范的TCP/IP协议栈,使得contiki可以直接和Internet通信。uIP包含了IPv4和IPv6两种协议栈版本,支持TCP、UDP、ICMP等协议,但是编译时只能二选一,不可以同时使用。Rime是一个轻量级、低功耗无线传感器网络设计的协议栈,该协议栈提供了大量的通信原语,能够实现从简单的一跳广播通信,到复杂的可靠的多跳数据传输等通信功能。Contiki操作系统的特点1)事件驱动(Event-driven)的多任务内核:Contiki基于事件驱动模型,即多个任务共享同一个栈(stack),而不是每个任务分别占用独立的栈(如uCOS、FreeRTOS、Linux等)。Contiki每个任务只占用几个字节的RAM,可以大大节省RAM空间,更适合节点资源十分受限的无线传感器网络应用。2)低功耗无线传感器网络协议栈:Contiki提供完整的IP网络和低功耗无线网络协议栈。对于IP协议栈,支持IPv4和IPv6两个版本,IPv6还包括6LOWPAN帧头压缩适配器,ROLLRPL无线网络组网路由协议、CoRE/CoAP应用层协议,还包括一些简化的Web工具,包括Telnet、http和web服务等。Contiki还实现了无线传感器网络领域知名的MAC和路由层协议,其中MAC层包括X-MAC、CX-MAC、ContikiMAC、CSMA-CA、LPP等,路由层包括AODV、RPL等。3)集成无线传感器网络仿真工具:Contiki提供Cooja无线传感器网络仿真工具,能够多对协议在电脑上进行仿真,仿真通过后,下载到节点上进行实际测试,有利于发现问题,减少调试工作量。除此之外,contiki还提供MSPsim仿真工具,能够对MSP430微处理器进行指令级模拟和仿真。仿真工具对于科研、算法和协议验证、工程实施规划、网络优化等很有帮助。4)集成Shell命令行调试工具:无线传感器网络中节点数量多,节点的运行维护是一个难题,contiki可以通过多种交互方式,如Web浏览器,基于文本的命令行接口,或者存储和显示传感器数据的专用程序等。基于文本的命令行接口是类似于Unix命令行的Shell工具,用户通过串口输入命令可以查看和配置传感器节点的信息、控制其运行状态,是部署、维护中实用而有效的工具。5)基于Flash的小型文件系统CoffeeFileSystem:Contiki实现了一个简单、小巧、易于使用的文件系统,称为CoffeeFileSystem(CFS),它是基于Flash的文件系统,用于在资源受限的的节点上存储数据和程序。CFS是充分传感器网络数据采集、数据传输需求以及硬件资源受限的特点而设计的,因此在耗损平衡、坏块管理、掉电保护方面、垃圾回收、映射机制方等方面进行优化,具有使用的存储空间少、支持大规模存储的特点。CFS的编程方法与常用的C语言编程类似,提供open、read、write、close等函数,易于使用。6)集成功耗分析工具:为了延长传感器网络的生命周期,控制和减少传感器节点的功耗至关总重要,无线传感器网络领域提出的许多网络协议都围绕降低功耗而展开。为了评估网络协议以及算法能耗性能,需要测量出每个节点的能量消耗,由于节点数量多,使用仪器测试几乎不可行。Contiki提供了一种基于软件的能量分析工具,自动记录每个传感器节点的工作状态、时间,并计算出能量消耗,在不需要额外的硬件或仪器的情况下就能完成网络级别的能量分析。Contiki的能量分析机制既可用于评价传感器网络协议,也可用于估算传感器网络的生命周期。7)开源免费:Contiki采用BSD授权协议,用户可以下载代码,且可以任意修改代码,无需任何专利以及版权费用,是彻底的开源软件。尽管是开源软件,但是contiki开发十分活跃,在持续不断更新和改进之中。Contiki操作系统的安装和测试安装contiki操作系统Contiki操作系统是在Linux系统下进行安装和配置的,有两种常见的安装方式,方法一种是下载已经安装好的镜像文件,用虚拟机Vmware直接打开;方法二是先安装ubuntu操作系统在进行contiki系统的下载和配置,这里简单介绍方法二的安装。在已经安装好ubuntu的操作系统中,用快捷键Ctrl+Alt+t打开虚拟终端,输入下面命令:sudoapt-getinstallbuild-essentialbinutils-msp430gcc-msp430msp430-libcbinutils-avrgcc-avrgdb-avravr-libcavrdudeopenjdk-7-jdkopenjdk-7-jreantlibncurses5-devdoxygengit输入用户密码等待下载完成后执行下面命令:gitclonegit:///contiki-os/contiki.gitcontiki等待命令执行完以后,就可以在/home/user/路径下找到contiki的系统文件,如图4.1所示。至此,contiki系统下载安装完成。图4.1用终端查看安装完的Contiki操作系统文件夹定制SDCCcontiki中不能直接完成cc2530的编译,所以需要下载SDCC的源代码进行编译,这个过程本质是一个定制SDCC的过程。在这里下载的并不是安装包,而是SDCC的源代码,我们用这些SDCC的源代码可以编译成一个SDCC安装包。SDCC的版本有7100和8447,我们在这里安装8447。我们一般将SDCC安装在/opt路径下,安装步骤如下:1)使用如下命令安装BoostC++Libraries。BoostC++Libraries是一组扩充C++功能性的经过同行评审(Peer-reviewed)且开放源代码程序库。大多数的函数为了能够以开放源代码、封闭项目的方式运作,而授权于Boost软件许可协议(BoostSoftwareLicense)之下。sudoapt-getinstalllibboost-graph-dev2)使用如下命令安装srecordsudoapt-getinstalllibboost-graph-dev等待这两部分完成以后就开始下载SDCC的源码。3)通过命令将目录切换在/opt目录下,然后通过SVN命令获得SDCC源代码,代码如下:cd/optsudosvnco-r8447/p/sdcc/code/trunk/sdcc等待下载完以后,可以再/opt目录下找到名为sdcc的文件夹。4)配置SDCCa.打开incl.mk文件,将最后一行MODELS=smallmediumlarge修改为MODELS=smalllargehuge。这里用gedit命令打开文件,命令如下:sudogedit/opt/sdcc/device/lib/incl.mkb.打开Makefile.in文件,找到TARGETS+=modelssmall-mcs51-stack-auto修改为TARGETS+=modelsmodle-mcs51-stack-auto。命令如下:sudogedit/opt/sdcc/device/lib/Makefile.inc.将目录切换在/opt/sdcc路径下,首先执行命令:sudo./configure--disable-gbz80-port--disable-z80-port--disable-ds390-port\--disable-ds400-port--disable-pic14-port--disable-pic16-port\--disable-hc08-port--disable-r2k-port--disable-z180-port\--disable-sdcdb--disable-ucsim./configure命令就是执行当前目录的名为configure的脚本,主要的作用是对即将安装的软件进行配置。接下来执行命令:sudomakemake的基本功能是自动根据makefile里的指令来编译源文件。等待执行完以后,最后执行命令:sudomakeinstallmakeinstall:将程序安装至系统中。如果原始码编译无误,且执行结果正确,便可以把程序安装到系统预设的可执行文件存放路径。d.验证安装安装完成后需要验证安装是否正确,可以回到home目录,输入以下命令:sdcc-v通过命令也可以查看SDCC可执行文件的路径。whichsdcc上面两条指令的执行结果如图4.2所示:图4.2检查SDCC安装结果e.测试SDCC如果SDCC安装成功,那么contiki就会变得非常简单。就会和IAR开发环境一样,首先需要编译工程以便生成hex文件,然后使用smartRFFlashProgrammer下载该.hex文件到目标板,最后便可通过串口调试助手等工具观察程序运行情况。使用命令进入cc2530dk目录中进行编译,命令如下:cdcontiki/examples/cc2530dk/makeTARGET=cc2530dk编译后的结果和生成的.hex文件如图4.3所示:图4.3cc2530dk编译生成.hex文件然后通过将.hex文件下载到开发板上,就可以进行,程序功能的测试。测试contiki操作系统通过以上步骤,安装了contiki系统并配置好SDCC,我们进入/hello-world目录测试contiki。输入如下命令,make后生成.native文件,运行.native文件,结果如图3.4所示。cd/home/user/contiki/examples/hello-world/make./hello-world.native利用快捷键Ctrl+c终止正在运行的程序。图4.4测试contiki

系统仿真本设计使用虚拟机安装乌班图系统,并且安装了Contiki操作系统使用cooja对智能家居网络进行仿真,最后使用安装了COAP插件的火狐浏览器实现了对节点的远程控制。Cooja仿真工具介绍Cooja是运行在Contiki操作系统上的一个模拟器,为仿真传感器网络而设计的。模拟器是用Java实现的,但是传感器节点上运行的代码是用C语言编写的。不像大多数无线传感器仿真器针对一个固定的仿真水平,Cooja实现跨级仿真。它允许同时在三个级别上仿真一个系统,分别是网络级别(或者应用程序级别),操作系统级别和机器代码指令级别。COAP协议的简单介绍在2010年3月,CoRE工作组开始制定CoAP协议,到目前为止,该协议还没有定稿。CoAP协议是为物联网中资源受限设备制定的应用层协议。CoAP是受限制的应用协议(ConstrainedApplicationProtocol)的代名词。在最近几年的时间中,专家们预测会有更多的设备相互连接,而这些设备的数量将远超人类的数量。在这种大背景下,物联网和M2M技术应运而生。虽然对人而言,连接入互联网显得方便容易,但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界,信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言,实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网,CoAP协议被设计出来。CoAP是一种应用层协议,它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧,最小的数据包仅为4字节。为了克服HTTP对于受限环境的劣势,CoAP既考虑到数据报长度的最优化,又考虑到提供可靠通信。一方面,CoAP提供URI,REST式的方法如GET,POST,PUT和DELETE,以及可以独立定义的头选项提供的可扩展性。另一方面,CoAP基于轻量级的UDP协议,并且允许IP多播。而组通信是物联网最重要的需求之一,比如说用于自动化应用中。为了弥补UDP传输的不可靠性,CoAP定义了带有重传机制的事务处理机制。并且提供资源发现机制,并带有资源描述。CoAP协议不是盲目的压缩了HTTP协议,考虑到资源受限设备的低处理能力和低功耗限制,CoAP重新设计了HTTP的部分功能以适应设备的约束条件。另外,为了使协议适应物联网和M2M应用,CoAP协议改进了一些机制,同时增加了一些功能。下图5显示了HTTP和CoAP的协议栈。CoAP和HTTP在传输层有明显的区别。HTTP协议的传输层采用了TCP协议,而CoAP协议的传输层使用UDP协议,开销明显降低,并支持多播。图5.1HTTP和CoAP的协议栈事务层(Transactionlayer)用于处理节点之间的信息交换,同时提供组播和拥塞控制等功能。请求/响应层(Request/Responselayer)用于传输对资源进行操作的请求和响应信息。CoAP协议的REST构架是基于该层的通信。CoAP的双层处理方式,使得CoAP没有采用TCP协议,也可以提供可靠的传输机制。利用默认的定时器和指数增长的重传间隔时间实现图5.1HTTP和CoAP的协议栈仿真过程打开虚拟机,按CTRL+ALT+T打开终端。图5.2终端界面进入COOJA目录输入antrun启动Cooja仿真器。图5.3启动Cooja点击File选择Newsimulation新建仿真。图5.4Cooja仿真器界面点击Motes添加sky节点,建立一个汇聚节点相当于RPL组网中的根节点也相当于家里的路由器,传感器网络中的信息最后都会传输到这一节点,并且浏览器也是通过这一节点对传感器节点进行控制。图5.5仿真器的Network界面然后添加传感器节点,传感器网络就是由这些节点用RPL协议组网后形成。这里我们添加了八个传感器节点,这些节点就代表智能家居中的冰箱、电灯、窗帘等可控制的电器或物品。截图中可以看出除了节点2和节点3都不能直接与汇聚节点通信,所以要用RPL协议进行组网实现信息的多跳传输。现在软件内的仿真已经基本完成,但是还要提供让浏览器访问的接口以实现远程控制。图5.6传感器网络的仿真在节点1上点击右键选择Motetoolsforsky1->SerialSocket(SERVER)添加访问接口。图5.7为浏览器访问添加接口对添加的接口进行配置,进入contiki-2.7/examples/er-rest-example/目录输入connect-router-cooja回车运行。图5.8对接口进行配置仿真系统测试在仿真界面点击Start运行传感器网络。图5.9运行中的传感器网络打开火狐浏览器输入汇聚节点的地址http://[aaaa::212:7401:1:101]/可以看到传感器网络中的所有节点地址。图5.10传感器网络中所有节点的地址现在虽然浏览器能访问传感器网络但是无法实现远程控制,因此在火狐浏览器上可以安装COAP插件使用COAP协议对传感器节点进行访问控制。安装好COAP插件后例如要控制节点9,在火狐浏览器地址栏输入节点9的地址coap://[aaaa::212:7409:9:909]:5683进入控制界面。图5.11COAP的控制界面点击左侧light->leds然后点击菜单中的POST方法可看到节点9的红灯被点亮,再次点击红灯熄灭。图5.12控制节点9的LED灯点击左侧sensors->temperature,然后点击上方的GET方法,可以看到输出框输出Temperatureis23℃.即通过GET方法可以获取传感器温度。图5.13获取传感器温度通过对温度的读取与LED灯的结合可以实现对传感器节点的数据获取与远程控制,虽然仿真只是表现为控制LED灯的亮暗但是在实际中可以换为电源开关等对传感器节点进行控制。并且浏览器界面的左侧菜单都可自定义,以实现更丰富的功能,但是水平所限未能实现更多更实用的功能这有待以后完善。点击tools->Radiomessages打开cooja自带的抓包工具对传感器网络进行分析。打开一条消息的详细信息可看见消息Type为RPL,由此可见传感器网络是由RPL协议进行了组网。图5.14RPL数据包

硬件实现WSN2530DK是采用TICC2530芯片开发的ContikiIPv6/6LOWPAN专业开发套件,工作在2.4GHzISM频段,基于windows下的IAREW8051集成开发环境,已移植Contiki源代码、驱动代码和协议栈。WSN2530DK简介WSN2530DK支持开放的IPv6/6LOWPAN无线网络,从此彻底摆脱复杂难懂的Zigbee协议,技术在国内领先。具有以下优势:1)完全基于Windows开发WSN2530DK配套开发环境以及开发工具均能够运行在Windows系统,可以充分利用windows友好的图形界面,免去原生态Contiki需要在Linux下输入命令进行开发的痛苦,免去开发者学习Linux的烦恼,降低学习难度,加快开发速度。2)IAREW8051集成开发环境IAR功能强大,编译器成熟稳定,并支持8051、MSP430、ARM等几乎所有的微处理器,而原生态的Contiki采用SDCC或者gcc编译器,存在很多Bug,对于新手而言,简直是噩梦,很多时候遇到问题不知道是代码错误还是编译器有问题,对于产品开发风险很大。3)专业的sniffer工具sniffer工具与著名的协议分析软件Wireshark配套使用,构成专业的网络分析工具,能够分析6LOWPAN,还能够分析Zigbee,功能十分强大,是网络分析、调试、部署和诊断的必备利器。4)提供网络拓扑显示工具WSNNetworkMonitor网络拓扑显示工具,提供友好的图形界面,实时显示网络中节点组网的拓扑结构、拓扑的变化、网络链路的好坏等,辅助用户直观理解组网的过程,是网络开发的必备工具。5)提供windows下的网关工具winslip6网关工具,可以将节点虚拟成电脑上的网口接口,只要在电脑上开启路由转发功能,就可以实现6LOWPAN网络和计算机网络之间路由和数据交换,用户可以轻松ping节点,或者Web访问节点。CC2530SOC芯片CC2530是用于2.4GHzIEEE802.15.4、ZigBee和RF4CE应用的一个真正的片上系统(SoC)解决方案。它能够以非常低的材料成本建立强大的网络节点。CC2530结合了领先的RF收发器的优良性能,业界标准的增强型8051CPU,系统内可编程闪存,8KBRAM和许多其它强大的功能。CC2530有四种不同的闪存版本:CC2530F32/64/128/256,分别具有32/64/128/256KB的闪存。CC2530具有不同的运行模式,使得它尤其适应超低功耗要求的系统。运行模式之间的转换时间短进一步确保了低能源消耗。其引脚如图6.1所示,具有以下优势:图6.1CC2530引脚电路图图6.2SM2530节点硬件结构1)市场份额最高:在无线自组网领域,国内市场份额达80%以上,技术最成熟,资料最丰富,应用最广泛。2)价格最低:目前芯片价格在9元以内,只需要一片晶振,是其它方案的1/2、甚至1/5,价格占绝对优势。在无线模块竞争无比激烈的今天,低成本就是最大的优势,这样才能大规模应用普及。3)硬件资源丰富:集成8051内核、256KBFlash、8KBSRAM、符合802.15.4的RF,以及丰富IO接口,完美满足绝大多数应用场合。通常无线组网对处理能力要求低,片面追求硬件高配置是不科学的,会导致处理器大部分时间空闲(空转),还会导致功耗高、芯片价格高。此外,Contiki属于非抢占的类似于线程的操作系统,本质上不适合主频高的处理器,不适合做复杂的运算。4)整体功耗低:好的方案不是看局部功耗或性能,而是看整体的效果。CC2530芯片高集成度,整体休眠功耗低于1uA,整体功耗低,而其它方案,如MCU+RF双芯片,通常RF功耗低,MCU功耗很高,总体功耗较高,而且两个芯片的休眠唤醒管理很复杂,唤醒时间长,需要设计复杂的休眠算法,整体平均待机功耗通常在1uA~20uA之间。5)软件开发简单:CC2530使用广泛,中英文资料以及相关代码超级多,容易上手,此外,CC2530专门为协议开发进行深度优化,增加了协议定时器、AES、地址过滤等高级功能,与射频数据交互更加方便,硬件支持各种低功耗模式,大大降低软件开发难度,而其它如MCU+RF方案,则需要软件实现AES加密和解密(很耗CPU)、与射频交互复杂、驱动开发难,同时导致处理的功耗高。WSN2530DK硬件组成WSN2530DK包括SM2530节点4个、SmartRF04EB仿真器(1个),以及配套的数据线等配件。4个节点中,1个可以作为网关(Borderrouter),其余3个可作为普通节点。所有4个SM2530节点通过烧写sniffer固件,均可作为抓包工具使用。SM2530节点硬件均配置高质量的虚拟串口,可以连接电脑使用USB供电和打印调试信息,或者代替Dongle节点作为Sniffer或者网关,十分灵活方便。同时节点均配有电池盒,可安装2节5号电池,便于组网测试。硬件结构如图6.2所示:SM2530节点主要组成部分如表6-1所示。表6-1SM2530节点主要组成部分组成部分数量说明核心芯片CC2530F2561节点核心无线SOC芯片,含MCU和RF,256KB的Flash、8KB的SRAM,2个UART/SPI串行接口,具有多种低功耗模式,射频符合IEEE802.15.4标准,最大可编程输出功率4.5dBm,QFN40封装。虚拟串口1将USB接口虚拟化为一个串口。通过串口助手等工具传输数据,主要用于输出代码调试信息。时钟晶振132K频率的时钟晶体振荡器,易于实现低功耗休眠以及唤醒。32M晶振1用于MCU高速处理以及无线数据收发。JTAG插针1用于下载程序和调试程序。用户按键1用户可控制的按键,可用于产生外部中断、脉冲等。复位按键1对系统进行复位。拨动开关2两个拨动开关,用于选择供电方式。I/O引脚12未使用的12个I/O引脚,用户可自定义功能。电源电路SM2530节点有三种供电方式,其硬件电路图如图6.3所示,供电方式的选择如表6-2所示。复位电路复位电路如图6.4所示。当用户按下SW1时,系统重新开始运行,进行初始化和相应的事件处理。复位电路只要是为了防止程序跑飞等。图6.3SM2530节点电源电路图6.4复位电路表6-2SM2530节点供电方式S1状态S2状态供电方式任意OFF/JTAGJTAG供电BATON电池供电USBONUSB供电USB_UART电路USB_UART电路如图6.5所示,主要实现USB和串口之间的转换,核心芯片是CP2012。要利用该芯片实现USB和串口之间的转换,需要在PC机上安装相应的驱动程序。图6.5USB_UART电路图JTAG电路JTAG电路如图6.6所示,主要完成程序的下载,这里采用10针的下载线,配套SmatrRF04仿真器进行程序下载。同时JTAG还具有供电的功能。图6.6JTAG电路IO扩展引脚WSN2530DK提供了12个IO口,用户可以自己定义相关的功能,进行扩展,如图6.7所示。图6.7IO扩展引脚电路图系统整体设计该系统主要包含信息采集模块和终端控制模块两部分,两模块之间通过miniUSB相连,整体设计图如图6.8所示。其中信采集模块主要完成基本信息的采集如温度、湿度和光照,并且执行终端的相关命令,完成相应的控制工作。终端控制模块主要完成数据的友好、可视化显示,使得客户能够清楚的观察到当前采集的各种数据,并通过相应的命令控制各个节点。图6.8系统整体设计数据采集在这一部分,各个节点通过无线的数据传输方式,将采集到的数据传送到汇聚节点,并完成汇聚节点从上位机收到的控制命令。在这里我们将contiki系统移植在IAR下进行程序的编写和配置,使节点之间完成通信,并在上位机通过coap来控制和访问传感器节点。汇聚节点图6.9SmartRF烧写程序我们在SM2530节点中选择一个节点作为汇聚节点,通过SmartRF软件将程序烧写到汇聚节点,如图6.9所示。在烧写程序时,仿真器的一端通过AB型USB和PC相连,一端通过10针的JTAG和SM2530节点相连,如图6.10所示,在这里我们需要将仿真器复位一次,使指示灯状态为绿色。汇聚节点烧写hex文件rpl-coap-brouter.hex。图6.10程序烧写的连接方式信息采集节点信息采集节点主要完成节点周围相应数据的采集,并将数据通过无线的方式发送给汇聚节点,同时完成来自上位机的控制命令。我们将SM2530的其他节点都作为信息采集节点,烧写采集信息的程序,我们加入自己的代码,来采集温度、湿度和光照,并完成节点上的LED灯和按键的控制,程序代码详见附录III。在这里我们通过IAR编写、编译程序,生成hex文件,再通过SmartRF软件完成节点程序的烧写。烧写完毕后,整个网络结构如图6.11所示。图6.11网络结构图终端控制上位机环境配置border通过虚拟串口与电脑连接,通过SLIP协议与电脑交互,电脑上通过winslip6软件模拟一个虚拟网口,实现与6LOWPAN网络之间的通信。1)使用devcon生成Loopback接口下载和系统相配的devcon文件,这里选择64位的版本,将该文件拷贝到windows安装目录:C:/windows/system32文件夹中。然后以管理员身份运行命令提示符,在命令行中输入如下命令:devcon.exeinstall%windir%\inf\netloop.inf*msloop该命令将在电脑上生成一个Loopback网络接口。运行后的结果如图6.12所示。然后执行ipconfig/all,显示出电脑上的网络接口信息,在电脑上多出如图6.13所示的网络接口,接口描述为:MicrosoftLoopbackAdapter,物理地址为:02-00-4C-4F-4F-50,我们通过此物理地址访问该网络。重启电脑,上述网络接口才能生效。图6.12生成一个Loopback网络接口图6.13生成的网络接口2)使用winslip6实现通信下载开发工具winslip6,将下载文件夹放置在一个特定的目录下,如D:\winslip6。主要方便在命令行中输入文件夹名字。以管理员权限打开命令提示符,进入到开发工具winslip6所在的目录。通过设备管理器查看汇聚节点所在的端口号,这里是COM3口,保证汇聚节点和电脑连接完好,并且整个网络正常运行。然后输入如下命令:winslip6-sCOM3-baaaa::-aaaaa::1/12802-00-4C-4F-4F-50-sCOM3指定所使用的串口设备,-baaaa::是将6LOWPAN网络的IP地址前缀设置为aaaa::,-aaaaa::1/128是设置该Loopback网络接口的IPv6址,后面的02-00-4C-4F-4F-50是Loopback网络接口的MAC地址(即MicrosoftLoopbackAdapter的物理地址)。输出结果如图6.14所示。图6.14Loopback网络接口的连接3)输出结果当winslip6运行之后,它在电脑里建立了到6LOWPAN网络的路由表,可以进行查看。打开另一个命令符窗口cmd.exe,输入如下命令:routePRINT-6该命令显示IPv6的路由表,在测试机中显示如图6.8所示。图6.15中可以看到“活动路由”中,有个表项:aaaa::212:4b00:53f:9476,这个IPv6地址是border的IPv6全局地址,说明电脑上已经可以建立了到达border的路由。另外,在“永久路由”中还有一个表项,其含义是所有前缀为aaaa::/64的IP地址,电脑都将数据包转发给aaaa::212:4b00:1d3:92e4节点,再由border转发给6LOWPAN网络中的节点。因此,和IP网络一样,只要建立了路由,就可以ping这个border节点,以及6LOWPAN中的其它节点。图6.15IPv6的路由表在命令提示符窗口输入命令:ping-6-taaaa::212:4b00:53f:9476其中后面的IP地址为border的全局IPv6地址。输出结果如图6.16所示。图6.16pingborder节点在这里也可以ping信息采集节点,会得到相同的回复信息,我们通过虚拟网络接口以及winslip6工具,实现了6LOWPAN网络与IPv6网络之间的互联互通。Web浏览器访问控制节点接入互联网是6LOWPAN相对于其它协议的重要优势,IETF组织制定了基于CoAP的轻量级Web服务,能够与HTTP快捷互换。6LOWPAN节点实现CoAP服务器,提供给外部访问,电脑作为CoAP的客户端,通过网关访问节点上的数据。电脑上需要安装firefox浏览器和Copper插件,这样就能够实现客户端的功能。我们以信息采集节点aaaa::212:4b00:53f:8f8c来说明。1)启动设备在完成之前的Loopback网络接口的配置和通过命令提示符访问后,启动安装有Copper插件的firefox浏览,在地址栏中输入coap://[aaaa::212:4b00:53f:8f8c]:5683。其中coap为传输协议,aaaa::212:4b00:53f:8f8c位信息采集节点的全局IPv6地址,5683为coap协议的端口号。点击Discover得到如图6.10所示的资源信息,可以看出,能通过汇集节点获得采集节点采集的数据,也能够通过电脑控制采集节点实现相应的操作。2)信息采集我们可以通过GET方法获取节点采集的数据,在这里我们可以获取温度temperature、湿度humidity和光照light。获取温度的方法如图6.11所示,首先点击sensors中的temperature,然后点击GET就可以可到温度值。湿度和光照的获取方法类似与温度的获取方法。图6.17firefox浏览器

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论