无线传感器网络操作系统文档格式.docx
《无线传感器网络操作系统文档格式.docx》由会员分享，可在线阅读，更多相关《无线传感器网络操作系统文档格式.docx（19页珍藏版）》请在冰豆网上搜索。
同其他操作系统一样，WSNOS是为了方便开发应用，提供物理设备的抽象和高协调性的通用函数实现。
它的独特性在于，资源极端受限（处理器速度、存储器大小、内存大小、通讯带宽、资源数量以及电源受限），设备特殊性和缺乏一致的抽象层次。
因此，WSNOS的设计策略必须是一个资源库，从中抽取一部分组成应用。
它致力于提供有限资源的并发，而不是提供接口或形式[10]。
伯克利开发的TinyOS[12]正是这样一套WSNOS系统。
1.3我们的研究调查
我们对该领域的前景进行了大量的研究调查，重要的需求和趋势可以归结如下：
1.工厂真正实现电子信息化需要WSN实地采集数据和监控。
文献[13]中谈到了WSN应用于工厂自动化生产线的问题。
传统的有线传感只能用在布线容易的短距离空间，而对很多长距离的监控则无能为力。
例如，输油管道的监控，需要在输油管道上散布很多传感器，并且互相之间要互通信息。
而以往的传感器需要布线，同时传感器之间不能互相通信，阻碍了这种应用。
但是，这种无线监控最大的困难是它不如有线传感器可靠。
2.WSN为城市监控，野外监控提供了技术手段。
用于监控生态环境、农作物生长环境、城市交通监控、大楼监控等。
大量的WSN节点的冗余可提高可靠性，但是它们需要长时间处于不维护状态，因此电池的寿命就成了这种应用的瓶颈。
3.WSN也可用于特殊物品监测，例如：
胎压监测、灭火器监测、危险物品监测等。
这些对物品的监测也必须要求很高的可靠性，而且要求低功耗以使其可以维持工作到所需的时间。
4.在军事上，WSN也为现代化的先进武器系统提供了新的技术基础。
例如：
地雷上装上WSN节点，可以与士兵身上的WSN节点通讯，识别敌我，而有选择性地爆炸。
这种节点涉及到人的生命安全，其可靠性的要求极高，同时也必须在足够时间内维持工作。
总之，这种应用前景关注去掉“两线”数据线和电源线的无线技术，前者随着RF射频硬件技术的发展而出现，后者随着低功耗的处理器，低功耗的收发器以及低功耗的传感器等低功耗硬件的发展以及电池技术的发展而得以实现。
然而，去掉数据线使得通讯变得不那么可靠；
去掉电源线使得供电时间的维持成为一个挑战。
因此，可靠性和低功耗已经成为了这种技术推广的瓶颈。
我们将主要研究从WSN操作系统软件的角度着手解决可靠性和低功耗的问题。
首先，与一般的嵌入式系统（如PDA，手机等）不同，WSN的资源更加受限，迫切需要系统软件的精心设计，才能满足可靠性的需求；
其次，电池技术的发展并不足以满足很长时间不维护的需求，而硬件也需要系统软件的管理才能充分发挥其低功耗特性。
这就需要系统软件采用最大限度降低运算功耗和通讯功耗的策略。
以下章节，首先介绍WSNOS的总体框架内容；
然后从操作系统的角度来介绍WSNOS的任务管理和内存管理等OS内核；
考虑到WSN以数据通讯为中心和低功耗的两大特点，介绍通讯的基本原理、低功耗通讯协议和一些低功耗实现技术，如：
电源管理服务、编译器技术、分布式处理、数据压缩等；
2WSNOS框架
文献[14]中，介绍了TinyOS的主要框架和内容，如图1，图2所示，代表了WSNOS的体系结构。
图1WSNOS总体框架
图1是WSNOS的总体框架。
物理层硬件为框架的最底层，传感器、收发器以及时钟等硬件能触发事件的发生，交由上层处理。
相对下层的组件也能触发事件交由上层处理。
而上层会发出命令给下层处理。
为了协调各个组件任务的有序处理，需要操作系统采取一定的调度机制。
图2提供了WSNOS组件的具体内容，包括一组命令处理函数，一组事件处理函数，一组任务集合和一个描述状态信息和固定数据结构的框架。
除了WSNOS提供的处理器初始化、系统调度和C运行时库（CRun-Time）3个组件是必需的以外，每个应用程序可以非常灵活地使用任何WSNOS组件。
这种面向组件的系统框架的优点是：
首先，“事件-命令-任务”的组件模型可以屏蔽低层细节，有利于程序员更方便地编写应用程序；
其次，“命令-事件”的双向信息控制机制，使得系统的实现更加灵活；
再次，调度机制独立成单独的一块，有利于为了满足不同调度需求进行的修改和升级。
3WSNOS内核
3.1WSNOS调度机制
由于WSNOS的特殊性，它的调度机制需要简单而实用。
下面以TinyOS为例，介绍WSNOS的调度机制。
3.1.1调度
TinyOS的调度模型为任务加事件的两级调度，调度的方式是任务不抢占事件要抢占，调度的算法是简单的FIFO，任务队列是功耗敏感的[12]。
调度模型有以下的特点：
（1）基本的任务单线程运行到结束，只分配单个任务栈，这对内存受限的系统很重要。
（2）FIFO的任务调度策略是电源敏感的。
当任务队列为空，处理器休眠，等待事件发生来触发调度。
（3）两级的调度结构可以实现优先执行少量同事件相关的处理，同时打断长时间运行的任务。
（4）基于事件的调度策略，只需少量空间就可获得并发性，并允许独立的组件共享单个执行上下文。
同事件相关的任务集合可以很快被处理，不允许阻塞，具有高度并发性。
TinyOS只是搭建好了最基本的调度框架，只实现了软实时[15]，而无法满足硬实时[16]，这对嵌入式系统的可靠性会产生影响[17]。
同时，由于是单任务的内核，吞吐量和处理器利用率不高，因此有可能需要设计多任务系统。
为保证系统的实时性，多采用基于优先级的可抢占式的任务调度策略。
依赖于应用需求，出现了许多基于优先级多任务的调度算法的研究。
[18]把TinyOS扩展成多任务的调度，给TinyOS加入了多任务的调度功能，提高了系统的响应速度。
[19]提出在TinyOS中实现基于时限（deadline）的优先级调度，有利于提高WSN系统的实时性。
[20]提出了一种任务优先级调度算法来相对提高过载节点的吞吐量以解决本地节点包过载的问题。
总之，调度决定了处理器的功耗，如TinyDB[11]就是使用好的调度策略来降低功耗的。
更为重要的是，各种调度算法也能更好地提高处理器的响应速度，从而提高系统的可靠性。
各种基于TinyOS调度算法的扩展研究，各自独立地使得高可靠性和低功耗分别得到满足。
3.1.2中断
在TinyOS中，代码运行方式为响应中断的异步处理或同步地调度任务。
TinyOS的每一个应用代码里，约有41%-64%的中断代码[21]，可见中断的优化处理非常重要。
对于低功耗的处理而言，需要长时间休眠，可以通过减少中断的开销来降低唤醒处理器的功耗。
目前通过禁用和打开中断来实现原子操作，这个操作非常的短暂（几个时钟周期--cycles）。
然而，让中断关掉很长时间会延迟中断的处理，造成系统反应迟钝。
TinyOS的原子操作能工作得很好是因为它阻止了阻塞的使用也限制了原子操作代码段的长度，而这一些条件的满足是通过nesC[21]编译器来协助处理的。
由于nesC编译器对TinyOS做静态的资源分析以及其调度模式决定了中断不允许嵌套。
在多任务模式下，中断嵌套可以提高实时响应速度。
3.1.3时钟同步
TinyOS提供获取和设置当前系统时间的机制，同时，在WSN网络中提供分布式的时间同步。
TinyOS是以通讯为中心的操作系统，因此更加注重各个节点的时间同步。
如：
传感器融合应用程序收集一组从不同地方读来的信息（如：
较短距离位置需要建立暂时一致的数据）；
TDMA风格的介质访问协议需要精确的时间同步；
电源敏感的通讯调度需要发送者和接收者在他们的无线信号开始时达成一致等[11]。
加州大学洛杉矶分校（UCLA）[22]、Vanderbilt[23]和加州大学伯克利分校（UCBerkeley）[24]分别用不同方法实现了时间同步。
这3个实现都精确到子毫秒级，最初打算开发一个通用的、底层的时间同步组件，结果失败了。
应用程序需要一套多样的时间同步，因此只能把时钟作为一种服务来灵活地提供给用户取舍使用。
某些情况允许逐渐的时间改变，但另一些则需要立即转换成正确的时间。
当时间同步改变下层时钟时，会导致应用失败。
某些系统，例如NTP（networktimeprotocol）通过缓慢调整时钟率同邻节点同步来规避这个问题。
NTP方案很容易在像TinyOS那样对时间敏感的环境中出错，因为时间即使早触发几毫秒都会引起无线信号或传感器数据丢失。
目前TinyOS采用的方案是提供获取和设置当前系统时间的机制（TinyOS的通讯组件GenericComm使用hook函数为底层的通讯包打上时间戳，以实现精确的时间同步[25]），同时靠应用来选择何时激活同步。
在TinyDB应用中，当一个节点监听到来自于路由树中父节点的时间戳消息后会调整自己的时钟以使下一个通讯周期的开始时间跟父节点一样。
它改变通讯间隔的睡眠周期持续时间而不是改变传感器的工作时间长度，因为减少工作周期会引起严重的服务问题，如数据获取失败。
在文献[26]中，J.Elson和D.Estrin给出了一种简单实用的同步策略。
其基本思想是，节点以自己的时钟记录事件，随后用第三方广播的基准时间加以校正，精度依赖于对这段间隔时间的测量。
这种同步机制应用在确定来自不同节点的监测事件的先后关系时有足够的精度。
设计高精度的时钟同步机制是传感网络设计和应用中的一个技术难点。
也有一些应用更重视健壮性而不是最精确的时间同步。
TinyDB只要求时间同步到毫秒级，但需要快速设置时间。
在TinyDB中，简单的，专用的抽象是种很自然的提供这种时间同步服务的方式，但是这种同步机制并不满足所有需要的通用的时间同步。
另外，还可以采取Lamport分布式同步算法[27]，并不全部靠时钟来同步。
3.1.4任务通讯和同步
任务同步是在多任务的环境下存在的。
因为多个任务彼此无关，并不知道有其它任务的存在，如果共享同一种资源就会存在资源竞争的问题。
它主要解决原子操作和任务间相互合作的同步机制。
TinyOS中用nesC编译器检测共享变量有无冲突，并把检测到的冲突语句放入原子操作或任务中来避免冲突[21]（因为TinyOS的任务是串行执行的，任务之间不能互相抢占）。
TinyOS单任务的模型避免了其他任务同步的问题。
如果需要，可以参照传统操作系统（例如μc/os）的方法，利用信号量来给多任务系统加上任务同步机制，使得提供的原子操作不是关掉所有的中断，从而使得系统的响应不会延迟。
在TinyOS中，由于是单任务的系统，不同的任务来自不同的网络节点，因此采用管道的任务通信方式，也就是网络系统的通信方式。
管道是无结构的固定大小数据流，但可以建立消息邮箱和消息队列来满足结构数据的通信。
3.2WSNOS内存管理
TinyOS的原始通讯使用缓冲区交换策略来进行内存管理。
当网络包被收到，无线组件传送一个缓冲区给应用；
应用返回一个独立的缓冲区给组件以备下一次接收。
通讯栈中，管理缓冲区是很困难的。
传统的OS把复杂的缓冲区管理推给了内核处理，以拷贝复杂的存储管理以及块接口为代价，提供一个简单的、无限制的用户模式。
AM通讯模型[28]不提供拷贝而且只提供非常简单的存储管理。
消息缓冲区数据结构是固定大小的。
当TinyOS中的一个组件接收到一个消息，它必须释放一个缓冲区给无线栈。
无线栈使用这个缓冲区来装下一个到达的消息。
一般情况下，一个组件在缓冲区用完后会将其返回，但是如果这个组件希望保存这个缓冲区待以后用，会返回一个静态地本地分配缓冲区，而不是依靠网络栈提供缓冲区的单跳通信接口。
尽管只有1个组件，任何时候只有一个进入给定缓冲区的指针，组件来回交换使用它们。
静态分配的内存有可预测性和可靠性高的优点，但缺乏灵活性。
不是预估大了而造成浪费就是小了造成系统崩溃，为了充分利用内存，可以采用响应快的简单的slab动态内存管理[29]。
4WSN通讯
通讯协议是WSNOS研究的另一大重点。
通讯协议的好坏不仅决定通讯功耗的大小，同时也影响到通讯的可靠性（包的丢失率，包过载等）。
TinyOS为满足这样要求的通讯协议提供了基于轻量级AM通讯模型的最小的通讯内核。
4.1AM通讯模型
[28]介绍了这种轻量级的AM通讯模型，它构成TinyOS极小内核的通讯系统，其他应用都建立在这个通讯系统之上。
AM消息包含用户级处理函数名称和作为参数传送的有效载荷，为了避免网络阻塞和保证充分的性能，消息处理函数必须被很快地执行和异步处理。
所有的这些措施都是为了实现低功耗的通讯。
尽管AM源于大规模并行处理机和计算群集（ComputingCluster），但是一些基本概念也适用于资源受限的网络小设备。
特别是轻量级的AM体系结构可作为杠杆来平衡扩展的通讯框架的需求和有效的灵活性。
而且基于事件处理函数触发模型，使应用级的开发者得以避免对数据的忙等，使系统能交迭地同其他活动通讯（如，同传感器交互或执行其它的应用）。
4.2WSN通讯协议
[11]介绍了AM为基础的单跳协议和多跳协议，如S-MAC[30]是其中一种单跳协议的低功耗实现；
文献[31-35]介绍了多跳通讯协议，主要解决自组织的网络路由。
简单介绍如下：
S-MAC基于RTS/CTS调度，并返回无线消息来减少监听的开销。
S-MAC保持分段操作（split-phase）和无拷贝特性。
所谓分段操作即：
在TinyOS中由于任务之间不能互相占先执行，所以TinyOS没有提供任何阻塞操作。
为了让一个耗时较长的操作尽快完成，一般来说都是将对这个操作的需求和这个操作的完成分开来实现，以便获得较高的执行效率。
自组织（Adhoc）的网络路由是一种不需要网桥（AP）的无线对等传输模式。
任两个传感器若在彼此的通讯覆盖范围内，则这两个传感器可直接互相通讯，共享资源。
它具有对称性，即B若在A的通讯范围内，则A也在B的通讯范围内；
但往往由于某些外部条件的限制，可能会造成这种对称的不协调。
若在两个相距较远的传感器之间通讯，可以寻找一个中间的传感器作为转发的节点，采用接力的方式来完成通讯过程。
利用这种方式可以增加无线网络的通讯范围，但随着传输次数增加，数据的正确率会降低，传输过程的可靠性也降低。
这种多跳路由一般可采用树状结构的集中，网络内部路由和分发（dissemination）3种形式。
比较普遍的是基于树结构的路由。
它包含父节点标识多跳数或从树根开始的深度（即：
父节点的多跳数加1）。
一个节点传送一个包给父节点，该节点再传给其父节点，直到包到达树根。
设计的关键问题是怎样建立路由树和怎样维护以及怎样转发以便提高传输的可靠性并降低功耗。
主要用到两种方法：
邻节点发现和连接质量估计服务；
支持包的封装和监视转发。
WSN系统中，基站连接到PC，发出广播，接收到广播的节点更新路由信息，并重新广播给通过它自己可以连接到基站上的那些节点。
这些节点记住第一次监听到的路由更新，就是相应的到基站的最短路径。
为了防止路由循环，时间被分成多个时间段，每个时间段路由更新广播一次。
4.3低功耗监听协议
文献[36]指出：
（1）主机模块MCU和收发模块占据电源消耗的绝大部分比重；
（2）Active（激活）状态耗能最多，相对而言Idle（休眠）状态耗能最少；
（3）收发模块比MCU耗能要多很多。
发送一个字节（byte）消耗的能量约等于11000个MCU计算周期所消耗的能量[37]，或是收发一位（bit）消耗的能量相当于MCU处理100条指令[12]；
从总体的消耗来看，收发数据所消耗的能量也是最多的。
如果我们能够让收发模块和MCU处于多数时间休眠，少数时间激活状态，那么就能明显地降低系统的总体功耗。
[10]介绍了两种典型的低功耗监听方式：
周期性多跳监听（PeriodicMulti-HopListening）和低功耗监听（LowPowerListening）。
宏观上进行周期性多跳监听，设置周期性采样的时间间隔来减少主机和通讯模块的激活工作时间，例如：
每100秒激活10秒，则减少了90%的能耗，但是限制了实际的带宽；
微观上进行低功耗监听，增加监听频率，把每100秒监听10秒变成每300微秒监听30微秒，这样可以在监听不到任何信息的时候让无线收发器处于休眠状态，并且能够在传送1/3位信息的时间内唤醒，但是需要额外花费传送5位信息的时间来检测信息的有无。
使用以上两种监听方式带来的降低功耗效果是显著的。
在[37]中作了详细的比较，两者都不采用时MCU和收发模块的功耗都很大；
只采用微观的低功耗监听，MCU的功耗明显降低，但是，收发模块的功耗降低不是很显著；
只采用宏观的周期性多跳监听，MCU和收发模块的功耗都显著降低；
两者都采用，MCU的功耗几乎为0，收发模块功耗显著降低。
可以用电池寿命数据来说明使用了以上两种监听方式带来的低功耗的效果。
两者都不采用时电池只能使用3天；
只采用微观的低功耗监听，电池可以使用6.54天；
只采用宏观的周期性多跳监听，电池寿命明显增加至65天；
两者都采用，电池寿命可以达到数年。
可见，采用这两种监听方式把电池的寿命从3天延长到几年，对于应用来说是具有突破性意义的。
Intel的下一代Mote原型[38]便采用这种策略来使得整个系统维持操作任务周期不超过1%。
5低功耗实现技术
5.1电源管理服务
文献[11]介绍了TinyOS的电源管理服务。
所谓服务就是提供功能库，供应用程序决定何时用何种功能，不是强迫应用必须使用，而是给应用很大的决定权。
以TinyDB为例，提供通讯调度的电源管理机制来降低功耗。
如图3所示：
（1）每个服务都可以通过调用stdcontrol.stop命令终止。
然后，负责管理硬件外围的组件可将这些硬件转换到低功耗状态。
（2）HPLPowerManagement通过检查处理器的I/O引脚和控制寄存器确定外部硬件的状态，把处理器调整到与之一致的低功耗模式。
（3）当处理器处在极低功率节能模式时多数情况下，TinyOS的定时服务可以和处理器配合工作。
（4）HPLPowerManagement直接控制处理器，确定何时将其转换到以下五种低功耗模式中的一种：
idle（休眠）、power-down（低功耗）、power-save（节能）、standby（准备状态）、extendedstandby（备用）。
从图3所示的TinyDB电源管理原理示例，可以看到通过软件可以控制硬件（MCU模块，无线收发模块以及传感器模块等）的低功耗模式从而达到节约电能的效果。
5.2编译技术
由于在传感器网络中，许多组件长时间不能维护，需要稳定和健壮性，而且资源受限要求非常有效的简单接口，只能静态分析资源和静态分配内存。
nesC就是满足这种要求的编译器，它使用atomic原子操作和单任务模型来实现变量竞争检测，消除了许多变量共享带来的并发错误；
它使用静态的内存分配和不提供指针来增加系统的稳定性和可靠性；
它使用基于小粒度的函数剪裁方法（inline）来减少代码量和提高执行效率（减少了15-34%的执行时间）；
并利用编译器对代码整体的分析做出对应用代码的全局优化[21]。
nesC提供的功能，整体地优化了通讯和计算的可靠性和功耗。
又如galsC编译器，它是对nesC语言的扩展，具有更好的类型检测和代码生成方法，并具有应用级的很好的结构化并发模型，很大程度上减少了并发的错误，如死锁和资源竞争；
galsC已经在伯克利的motes实现了且做到了和TinyOS/nesC的程序库兼容，同时采用了WSN的多跳协议来证实这种语言的有效性[39][40][41]。
5.3分布式技术
计算和通讯的整体效率的提高需要用到分布式处理技术。
借鉴分布式技术，实现优化有两种方式：
计算迁移和数据迁移。
数据迁移是把数据从一个节点传输到另一个节点，然后由后一个节点进行处理。
而计算迁移是把处理数据的计算过程从一个节点传输到另一个节点。
在WSN系统中，假设节点运行的程序一样，那么计算过程就不用迁移，只要发送一个过程的名字就可以了，这也就是AM通讯模型的做法[42][43]。
5.4数据压缩
文献[2]描述的GDI项目中，使用Huffman编码或Lempel-Ziv对数据进行了压缩处理，使得传输的数据量减少了2-4倍。
但是，当把这些压缩数据写入存储区时，功耗却增加了许多。
综合起来并未得到好的功耗结果。
由于GDI项目的重点在于降低系统的功耗，因此它并未分析压缩处理同增加系统可靠性的关系，最后它摒弃了数据压缩传送的方法。
事实上，可以对数据压缩法给功耗和可靠性带来的影响作进一步分析。
1WSN在PC机上的模拟器技术
研究WSN的低功耗和高可靠性，需要有一个PC模拟环境，这样才会有一个很好的定量分析的实验基础。
最近几年对WSN在PC机上的模拟器技术也有很多研究，有对WSN的框架模拟[44][45][46]，在模拟器上进行功耗实验[47][48][49][50][51][52]，以及在模拟器上进行协议的研究[53][54][55]。
可以看到，目前的WSN模拟器，一般集中在对功耗和协议的模拟评估，而对可靠性测量的模拟以及计算的量化模拟很少，同时把计算和协议综合起来评估功耗和可靠性的模拟器则未见报道。
建立这样一套模拟器系统对低功耗和高可靠性的量化分析是非常有意义的。
2我们的工作
我们WSN项目软件组的研究重点在于WSNOS的基础框架的研究，提供一个高可靠性，低功耗的WSN系统软件。
因此，我们主要在进行以下几个方面的研究：
（1）WSN操作系统内核的实时性，多任务调度对增加系统可靠性的研究；
（2）WSNOS的动态内存分配对支持OS多任务调度的资源节省的作用的研究；
（3）通讯协议综合节能和可靠性研究；
（4）开发可靠性评估模拟器以及低功耗和可靠性两者结合的评估模拟器以对
（1）-（3）进行量化评估；
升级会员 