分类： 嵌入式
2012-10-13 21:51:09
无线传感网络是高度动态的网络，因为节点可能由于严酷的环境条件和电源消耗而挂掉。并且，无线传感网络是由小型设备配置这受限的资源组成的网络，比如受限的内存，计算能力。无线传感网络总是工作在一种不被注意的模式，在有些情况下，可能被替换掉，所以那是基本的原则去最优化每个节点的寿命。无线传感网络的这些优点增加了操作系统的设计难度。这个调查旨在提出当前的OS，并且指出这os优缺点，关注新兴无线传感应用的需求。对于WSNs的os已经有了测试，os的体系结构，编程模型，调度，内存管理，保护，和通信，协议，资源共享，对实时任务的支持，可扩展性，这些特性在实时和非实时WSN操作系统都做了调查。
关键字：无线传感网络（WSN）；操作系统；嵌入式操作系统；实时操作系统（RTOS）
1， 简介：
微电子领域的发展已经 导致了小型化、低成本的传感器发展、可以通过无线通信。一个无线传感器节点是由微控制器、接收器、内存、数字转换器组成。
传感器节点用来监视各种自然或者认为的现象，比如居住监测，野生监测，病人监测，工业生产过程监测和控制，战争监测，交通监测，家庭自动化等等。最重要最关键的资源是energy（特别是用电池供电）和受限的主存，一般只有几千个字节，在无线传感中用到的微控制器相对传统的CPU来说，主频低些。这些资源受限的传感器正是SOS的代表。传感器节点在通过高速通行的传感领域和分布式处理领域需要实现高质量和容错能力。无线传感领域的应用正在快速发展并且新的应用在无线网络正在快速崛起。
这些os扮演者资源管理者的角色。
一个os控制资源 在时间 和空间两个部分。
2 WSN OS 设计所关心的主要方面
2.1 体系结构
体系结构影响内核的大小以及他为应用程序提供服务的方式。有整体结构，微核结构，虚拟机结构，分层结构。
整体式：整体式实际上没有包含任何结构，os提供的服务都是分离的，每个服务提供一个结构给其他服务，这样的结构需要将所有的服务捆绑在一起成为一个系统镜像。这样结构的有点就是通信开销小，缺点就是系统难以理解和修改，不可靠，难以维护。
微内核结构：微内核结构是指内核只提供比较少的功能，这样就会有比较小的内核size,大部分的Os功能都是通过用户层服务如：文件服务，内存服务，时间服务等，如果某种服务失效，整个系统并不会崩溃，微内核结构提供比较好的可靠性，一定的扩展性和裁剪性。微内核的结构的缺点是在效率太差，由于频繁的状态切换（用户态 系统态）。微内核结构被选来当着很多嵌入式OS的结构，由于它比较小的内核大小以及在WSN应用中状态切换的数目被认为是很少的，相比传统的系统来说。
虚拟机模型：主要思想是为用户呈现出一个类似于硬件的虚拟机，虚拟机拥有硬件的所有特性，主要优点是：可移植性，缺点：效率太差。
分层结构模型;将服务分为很多层，优点：易于管理，容易理解，可靠性，缺点：从OS设计的远景来看，这并不是一个合理的结构。
OS for ＷＳＮ 应该有比较小的内核，结构必须有一定的扩展性，必须是灵活的，只将需要的服务装载到系统中去。
２.２编程模型
ＯＳ所支持的编程模型对于应用程序的开发有着重大的影响。对于典型的ＷＳＮ ＯＳｓ有两种主流的编程模型：事件驱动模型和多线程编程模型，多线程编程模型是对大多数程序员所熟知的，但是仅限于他的含义而不是在资源紧缺的场合。所以被认为是在资源紧缺的的设备如传感器上是不适合的。事件驱动被认为是在资源受限的设备上更适合，但是在传统的应用开发中被认为是不便的。所以研究者致力于开发一种轻量级的多线程编程模型为ＷＳＮ ＯＳｓ．
2.3调度
传统调度：低延迟，高吞吐量，高资源利用率，公平性
ＷＳＮ调度：依赖于应用的特性，对于有实时需要的需求，要用实时调度算法，对于非实时调度的任务，非实时调度算法会更有效。
ＷＳＮ 现在应用于实时和非实时环境中，所以一个ＷＳＮ ｏｓ需要提供能够适应应用需要的调度算法，并且一个合适的调度算法应该需要较少内存和低功耗的。
２.４ 内存管理和保护
静态分配和动态分配
２.５ 通信协议支持
２.６ 资源共享
３，对实时应用的支持
Ｗｉｒｅｌｅｓｓ Ｍｕｌｔｉｍｅｄｉａ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ（ＷＭＳＮｓ）．ＯＳ ｆｏｒ ＷＳＮ应该提供通信协议的补充来支持实时多媒体信息流。例如，ＯＳ可以提供一个ＭＡＣ协议能够减少ｅｎｄ ｔｏ ｅｎｄ ｄｅｌａｙ ｏｆ multimedia streams.并且OS的设计者应该致力于提供实时通信协议在网络层和传输层，并且，应当提供API为程序员，允许他们在通信协议的顶端操作OS所支持的协议。
首先：WSNs和WMSNs是用来捕获和传输有无处不在的传感器收到的信息在网络中。所以，通信协议扮演了很重要的角色在这些网络中。资源受限以及无线传输媒介导致不能使用传统的分层协议如TCP/IP。
其次：TCP是为有线网络设计的，它在无线网络中的表现很差，并且在WMSNs中TCP也是不被推荐的，因为他的数据流和拥塞控制机制，UDP由于没有任何确认状态的信息，所以也不适用。
所以TCP UDP都不是WMSNs的理想通信协议。
跨层结构协议是一种新兴的很有前景的对于无线通信的技术。在跨层设计中，MAC层根据不同的链路状态选择合适的纠错技术。网络层可以通过应用层的输入和物理层来选择路径。跨层结构能够适应协议栈去满足应用层需要的这种行为。或者相反，它能适应应用到链路层的状态。目前，假设SWNs只在一个节点运行一个应用，结果是，研究者们已经研发出了跨层结构可以有效的再无线传感网络中工作。
当前，现代的OS for WSN 应当同一种通信协议能够实现跨层通信，并且能够在于应用通信的协议上自由调整参数。OS应当提供支持实时应用的传输协议。这个实时传输协议应当能够监控网络条件，减少在网络上的拥塞，以便于实时数据流能够被有效接收，并且OSing个提供一种路由协议，根据应用的服务质量要求来选择路径，当然，它还必须支持根据包文优先级来调度的MAC层算法。
4，TinyOS
TinyOS的构件包括网络协议、分布式服务器、传感器驱动及数据识别工具。其良好的源于执行模型。
4.1 体系结构
TinyOS 属于整体式结构。TinyOS使用组件模型并且根据应用的需要，不同的组件被组合在一起组成一个镜像，在终端节点运行。一个组件是一个独立的计算实体，它会引出一个活多个接口，组件有三个计算机性抽象：命令，事件，和任务。内部组件通信的模型是命令和事件，任务是用来描述内部组件的并行，一个命令是一些服务的请求，而事件信号表示着服务的完成。TinyOS提供了一个单独的共享栈，在内核空间和用户空间是没有区分的。
4.2 编程模型
早起版本的TinyOS不支持多线程，应用开发都是严格的遵照事件驱动编程模型。TinyOS 2.1版本听增加了对多线程的支持。这些TinyOS线程被称作 TOS 线程。原作者之处问题的关键是：节点拥有受限的资源，事件驱动更适合。然后抢占式线程提供了更加直观的编程模型。 TOS线程包使得多线程编程模型在事件驱动模型上有效的工作。TOS线程是先后兼容的，
4.3 调度
早起版本的TinyOS支持非抢占的先来先服务调度算法，所以那写版本的TinyOS不支持实时应用，TinyOS执行模型的核心是任务在ＦＩＦＯ的模式下完成。任务对于任务是完整的，但是中断，命令和它所调用的时间却不是原子的。缺点是：等待时间过长，而且对短任务不公平。
ＴｉｎｙＯＳ的原作者宣传已经支持了ＥＤＦ算法，去解决实时调度任务。ＥＤＦ调度算法不会产生稳定的调度当资源不能满足的时候，所以ＴｉｎｙＯＳ不能提供硬实时调度算法，如果不同的线程需要共同的资源。
４.４内存管理和保护
４.５ 通信协议支持
早期版本的ＴｉｎｙＯＳ提供了两把多跳协议：分发和ＴＹＭＯ。分发协议可靠的讲数据分发到网络上的每个节点。这个协议运行管理员重新配置和改变网络，分发协议提供两个接口：Ｄｉｓｓｅｍｉｎａｔｉｏｎ 和 disseminationUpdate，生产者调用disseminationUpadta，每次生产者想要分发消息都会调用disseminationUpdate.change()命令。另一方面，dissemination value 接口是为消费者准备的。事件DisseminationValue.changed()会在分发数据改变时signaled.TYMO协议时分发协议的补充，是一个为移动自组网的路由协议。
lin 已经研发出了新的DIP，一种新的为传感网络设计的分发协议。DIP是数据发现和分发协议，其规模可以达到数百。TinyOS version2.1.1now also provides supportfor 6lowpan。
在MAC层，TinyOS提供了下列补充协议：一个单跳TDMA协议，aTDMA/CSMA 混合协议实现最大化的Z-MAC B-MAC，还有一个可实现的IEEE802.15.4 MAC协议
4.6 资源共享
TinyOS 用了两种机制来管理共享资源：虚拟化和 completion events（完成事件？）虚拟化资源出现在每个独立的实例中，应用程序单独使用它。资源不能够被虚拟化的将会通过或completion events 来处理，TinyOS中的GenericComm 通信协议 可以被不同的线索共享，这是不能被虚拟化的。GenericComm每次只能发送一个数据包，在这个时间段里其他的发送操作都会失败，这样的共享资源会通过completion events来处理，它来通知等待的线程什么时候一个特定的线程完成。
4.7 支持实时应用
4.8 新增特性
文件系统：TinyOs提供了一个单层的文件系统，这个文件系统的原理是它假设只有一个应用跑在一个给定的节点上在特定时间。由于节点内存是受限的，有个单层的文件系统还是很有效的。
数据库支持：传感器节点的目的是感知 ，执行计算机指令，存储和发送数据。说以TinyOS提供了以TinyDBR为格式的数据库支持。
安全支持：在无线广播媒介中，通信安全是必须的。
模拟支持：
语言支持：TinyOS是用NesC 做出来的，NesC 是C的一种扩展语言
支持平台：Mica，mica2 micaz telos tmote
文档支持：TinyOS有丰富的文档资源，可以在上找到
5 contiki
contiki是一种轻量级的开源OS，C编写。contiki是一种高可移植性的os，是基于事件驱动的内核。contiki提供了可抢占多任务可以用到individua process level ，一个典型的contiki配置需要2k的RAm和 40K的rom，一个完整版的contiki安装包括：多任务内核，可抢占线程，原始级线程，TCP/IP网络，IPv6,一个图形界面窗口，一个web浏览器，一个私人web服务器，一个简单的telnet客户端，一个屏保程序，和虚拟网络计算。
5.1 体系结构
contiki OS 遵循的是模块化体系结构。在内核层他遵循时间驱动模型，但是它提供线程对于特殊的应用过程。contiki包含了一个轻量级的时间调度器，他可以分发事件到正在运行的进程。进程的执行是由内核分发的时间激发的或者被轮询的。轮询机制是用来防止竞争机制的，任何调度的事件都会运行完成，然而，事件处理程序可以使用内部机制来抢占。
contikiOs提供两种事件EW：同步事件和异步事件。不同点在于同步事件理解分发给目标进程并且导致调度。异步事件是有点像先调用入队操作，稍后再发生给目标进程。
contiki中用到的轮询机制就像高优先级的事件，它可以在每个同步事件之间调用，当一个poll被调度，all processes that implement a poll handler are called in order of their priority.
所有的OS 工具如：传感数据处理，通信，设备发送 都是以服务的形式提供的，每个服务都有他的接口和实现，应用层使用某个特定服务时，必须知道服务的接口，应用并不关系一个服务的具体实现，
5.2 编程模型
contiki支持可抢占多线程调度，多线调度被实现为一个库在事件驱动的内核上，当应用需要的时链接进来。contiki的多线程库分为两个部分，与平台相关部分和 与平台无关部分，与平台无关部分是与事件内核相联系的，与平台相关部分 implements stack switching and preemption primitives,since preemption si supported ,preemption is implemented using the timer interrupt and the thread state is stored on a stack.
多线程，原始线程。特点：占用很少内存(每个线程2个字节），没有多又多余的栈为线程，高可移植性（全部是由c语言实现的，没有与体系机构相关的汇编代码存在），事件是一直运行到结束的（应该是说，一个时间会一直运行，即使被中断还是会到这里，直到执行完毕），contiki不允许中断服务函数post new events，所以contiki没有通过进程同步控制。
5.3 调度
contiki内核是基于事件的，多以没有采用任何复杂的调度算法。如果事件到来则会被处理，中国中断到来，会根据其中断优先级进行调度。
5.4内存管理和保护
contiki支持动态内存管理，除此之外，还支持动态的链接程序。为了是contiki不产生碎片，contiki用了一种内存管理分配器，其主要职责是：通过链接不是使用的内存来保证所分配的内存不产生碎片。所以，一个程序使用内存管理分配器不能保证他分配的内存是固定在一个地方的。
对于动态内存管理，contiki也提供了内存块管理功能，这个库提供简单但有效的内存管理功能，对于固定长度的内存块。内存块是用MEMB（）宏来静态声明的，内存块通过memb_alloc()函数在声明的内存块中分配内存。
值得一提的是，contiki没有提供任何内存保护机制在不同的应用中。
5.5 通信协议支持
contiki 支持丰富的通信协议，在contiki，一个应用可以用两个版本的IP，IPv4 和IPv6，contiki提供了uip，uip不需要 与他通信的协议时一个完整的协议栈，但是它可以与一个运行着一个相似的轻量级的协议栈通信，uip是有c语言写的，它只支持一个网络接口，并且它支持TCP UDP 和IP协议层。
contiki提供另一种轻量级的分层协议栈，叫做 Rime，是基于网络的通信。Rime提供单跳单播，单挑广播，和多跳通信支持，Rime协议支持尽最大努力交付和可靠传输。在多跳通信中，Rime运行应用程序运行它们自己的路由协议，应用层允许扩充rime协议中没有实现的部分。
contiki不支持多播通信，所以contiki不能提供任何组播通信的协议，如ICMP MLD协议。
contiki提供了一种RPL（IPv6 路由协议为低功耗和lossy（有损耗的）网络)。 contikiRPL，
contikiRPL操作低功耗无线链路和有损耗的有线链路。
5.6 资源共享
事件是一直运行到结束的，并且contiki不允许中断服务函数产生新的事件，contiki提供串行的访问所有资源。
5.7 支持实时应用。
contiki提供任何对实时应用的支持，因此，在contiki中没有任何实时调度的算法。在网络协议栈方面来看，contiki不提供任何考虑Qos需求的多媒体应用。并且，contiki提供了微型IP协议栈，在不同层之间的通信是不允许的。
5.8 新增特性
coffee 文件系统:
contiki 为flash-based 传感器设备通过了Coffee 文件系统，设计此文件系统的目的是为创建一种有效地可移植存储提供一个编程接口。Coffee 提供了一个与平台无关的存储抽象通过一种有效的编程接口。Coffee需要5k ROM 用于存储代码，以及0.5k的RAM在运行时。一个简单连续的页结构正在被使用，Coffee 也引入了微日志去处理文件修改，而不是用一个增长型的日志结构，因为连续的页结构文件数据元，Coffee 为每个文件创建了一个小的固定的footprint。flash 内存被分成了逻辑页它的大小一般是和flash内存页大小一致。 如果文件的大小在事前不知道，Coffee 分配一个预定义数量的页为文件，稍后，如果默认的文件大小不是很有效，Coffee 创建一个新的大点的文件，并且把旧的文件拷贝过去，为了提高文件系统的效率，Coffee默认提供了一个8个条目的RAM元数据cache，coffee提供了垃圾回收机制，它可以重造废弃的页，当一个文件保留的请求不能被满足的话，为文件分配页的时候， Coffee用一种首次匹配算法，flash 内存 会受到使用次数的限制，每次它的页擦写都会增加它记忆单元失效的危险。Coffee使用一种磨损评估，目的是平均的使用每个扇区，减小一些扇区因使用过度而废弃的危险，Coffee提供了以下API为应用程序员。open(),read(),modify(),seek(),append(),close()。
安全支持：
contiki不提供通信安全保护。一个提议补充一个安全通信协议名字 contikiSec正在被提出。
仿真支持：
contiki提供了传感网络仿真通过Cooja。
语言支持：
contiki支持C语言。
支持平台：
contiki支持这些传感器平台： Tmote AVR MCU
文档支持：
contiki文档可以在 上找到。
6 MANTIS
