無線感測器網路作業系統

WSN作為綜合了感測器、嵌入式計算、及無線通信等3大技術的新興領域，可以實現人與自然物以及物與物對話的無處不在的通訊和計算。從火星探測到野生候鳥的監測，從智慧型房屋到車輛監測和跟蹤，從軍事“智慧型塵埃”（Smart Dust）到輔助足球裁判，從膠囊腸鏡到住院病人病情監控，從森林防火到預測山洪暴發，從人體內藥物劑量控制到精細農業……，廣闊的套用前景掀起了國內外對WSN的研究熱潮。

基本介紹

• 中文名：無線感測器網路作業系統
• 性質：網路作業系統
• WSN：掀起了一場後PC時代的革命

緒論

近幾年來，無線感測器網路（WSN）掀起了一場後PC時代的革命。
綜合各種套用，WSN有自己的許多特點。首先，WSN是一種嵌入式系統，提供分布處理，動態和適應性；其次，它由以通訊為中心的大數量的小型和微型數據採集設備構成，其主要特徵為靈活、自組織、嚴格資源限制，並且需要實時處理同長時間的單任務串列處理並存，同時大部分時間保持低功耗狀態。

2 WSN作業系統（WSNOS）

俗話說：“萬丈高樓平地起，一力承擔靠地基”，WSN的作業系統(WSNOS)是WSN系統的基本軟體環境，是許許多多的WSN套用軟體開發的基礎。WSNOS不是特定的系統/用戶界面，也不是特定的一系列系統服務，而是定義了一套通用的界面框架，允許應用程式選擇服務和實現；它提供框架的模組化，以便適應硬體的多樣性，同時允許應用程式重用通用的軟體服務和抽象。同其他作業系統一樣，WSNOS是為了方便開發套用，提供物理設備的抽象和高協調性的通用函式實現。它的獨特性在於，資源極端受限（處理器速度、存儲器大小、記憶體大小、通訊頻寬、資源數量以及電源受限），設備特殊性和缺乏一致的抽象層次。因此，WSNOS的設計策略必須是一個資源庫，從中抽取一部分組成套用。它致力於提供有限資源的並發，而不是提供接口或形式。伯克利開發的TinyOS正是這樣一套WSNOS系統。

3 WSN需求和趨勢

1）工廠真正實現電子信息化需要WSN實地採集數據和監控。文獻中談到了WSN套用於工廠自動化生產線的問題。傳統的有線感測只能用在布線容易的短距離空間，而對很多長距離的監控則無能為力。例如，輸油管道的監控，需要在輸油管道上散布很多感測器，並且互相之間要互通信息。而以往的感測器需要布線，同時感測器之間不能互相通信，阻礙了這種套用。但是，這種無線監控最大的困難是它不如有線感測器可靠。
2）WSN為城市監控，野外監控提供了技術手段。用於監控生態環境、農作物生長環境、城市交通監控、大樓監控等。大量的WSN節點的冗餘可提高可靠性，但是它們需要長時間處於不維護狀態，因此電池的壽命就成了這種套用的瓶頸。
3）WSN也可用於特殊物品監測，例如：胎壓監測、滅火器監測、危險物品監測等。這些對物品的監測也必須要求很高的可靠性，而且要求低功耗以使其可以維持工作到所需的時間。
4）在軍事上，WSN也為現代化的先進武器系統提供了新的技術基礎。例如：地雷上裝上WSN節點，可以與士兵身上的WSN節點通訊，識別敵我，而有選擇性地爆炸。這種節點涉及到人的生命安全，其可靠性的要求極高，同時也必須在足夠時間內維持工作。

總之，這種套用前景關注去掉“兩線”數據線和電源線的無線技術，前者隨著RF射頻硬體技術的發展而出現，後者隨著低功耗的處理器，低功耗的收發器以及低功耗的感測器等低功耗硬體的發展以及電池技術的發展而得以實現。然而，去掉數據線使得通訊變得不那么可靠；去掉電源線使得供電時間的維持成為一個挑戰。因此，可靠性和低功耗已經成為了這種技術推廣的瓶頸。

從WSN作業系統軟體的角度著手解決可靠性和低功耗的問題分析。首先，與一般的嵌入式系統（如PDA，手機等）不同，WSN的資源更加受限，迫切需要系統軟體的精心設計，才能滿足可靠性的需求；其次，電池技術的發展並不足以滿足很長時間不維護的需求，而硬體也需要系統軟體的管理才能充分發揮其低功耗特性。這就需要系統軟體採用最大限度降低運算功耗和通訊功耗的策略。

WSNOS框架

WSNOS的總體框架。物理層硬體為框架的最底層，感測器、收發器以及時鐘等硬體能觸發事件的發生，交由上層處理。相對下層的組件也能觸發事件交由上層處理。而上層會發出命令給下層處理。為了協調各個組件任務的有序處理，需要作業系統採取一定的調度機制。
WSNOS組件的具體內容，包括一組命令處理函式，一組事件處理函式，一組任務集合和一個描述狀態信息和固定數據結構的框架。除了WSNOS提供的處理器初始化、系統調度和C運行時庫（C Run-Time）3個組件是必需的以外，每個應用程式可以非常靈活地使用任何WSNOS組件。
這種面向組件的系統框架的優點是：首先，“事件-命令-任務”的組件模型可以禁止低層細節，有利於程式設計師更方便地編寫應用程式；其次，“命令-事件”的雙向信息控制機制，使得系統的實現更加靈活；再次，調度機制獨立成單獨的一塊，有利於為了滿足不同調度需求進行的修改和升級。

WSNOS核心

由於WSNOS的特殊性，它的調度機制需要簡單而實用。下面以TinyOS為例，介紹WSNOS的調度機制。

1.1 調度

TinyOS的調度模型為任務加事件的兩級調度，調度的方式是任務不搶占事件要搶占，調度的算法是簡單的FIFO，任務佇列是功耗敏感的。調度模型有以下的特點：
a) 基本的任務單執行緒運行到結束，只分配單個任務棧，這對記憶體受限的系統很重要。
b) FIFO的任務調度策略是電源敏感的。當任務佇列為空，處理器休眠，等待事件發生來觸發調度。
c) 兩級的調度結構可以實現優先執行少量同事件相關的處理，同時打斷長時間運行的任務。
d) 基於事件的調度策略，只需少量空間就可獲得並發性，並允許獨立的組件共享單個執行上下文。同事件相關的任務集合可以很快被處理，不允許阻塞，具有高度並發性。
TinyOS只是搭建好了最基本的調度框架，只實現了軟實時，而無法滿足硬實時，這對嵌入式系統的可靠性會產生。同時，由於是單任務的核心，吞吐量和處理器利用率不高，因此有可能需要設計多任務系統。為保證系統的實時性，多採用基於優先權的可搶占式的任務調度策略。依賴於套用需求，出現了許多基於優先權多任務的調度算法的研究。把TinyOS擴展成多任務的調度，給TinyOS加入了多任務的調度功能，提高了系統的回響速度。[提出在TinyOS中實現基於時限（deadline）的優先權調度，有利於提高WSN系統的實時性。提出了一種任務優先權調度算法來相對提高過載節點的吞吐量以解決本地節點包過載的問題。
總之，調度決定了處理器的功耗，如TinyDB就是使用好的調度策略來降低功耗的。更為重要的是，各種調度算法也能更好地提高處理器的回響速度，從而提高系統的可靠性。各種基於TinyOS調度算法的擴展研究，各自獨立地使得高可靠性和低功耗分別得到滿足。

1.2 中斷

在TinyOS中，代碼運行方式為回響中斷的異步處理或同步地調度任務。TinyOS的每一個套用代碼里，約有41%-64%的中斷代碼，可見中斷的最佳化處理非常重要。對於低功耗的處理而言，需要長時間休眠，可以通過減少中斷的開銷來降低喚醒處理器的功耗。目前通過禁用和打開中斷來實現原子操作，這個操作非常的短暫（幾個時鐘周期--cycles）。然而，讓中斷關掉很長時間會延遲中斷的處理，造成系統反應遲鈍。TinyOS的原子操作能工作得很好是因為它阻止了阻塞的使用也限制了原子操作代碼段的長度，而這一些條件的滿足是通過nesC編譯器來協助處理的。由於nesC編譯器對TinyOS做靜態的資源分析以及其調度模式決定了中斷不允許嵌套。在多任務模式下，中斷嵌套可以提高實時回響速度。

1. 3 時鐘同步

TinyOS提供獲取和設定當前系統時間的機制，同時，在WSN網路中提供分散式的時間同步。TinyOS是以通訊為中心的作業系統，因此更加注重各個節點的時間同步。如：感測器融合應用程式收集一組從不同地方讀來的信息（如：較短距離位置需要建立暫時一致的數據）；TDMA風格的介質訪問協定需要精確的時間同步；電源敏感的通訊調度需要傳送者和接收者在他們的無線信號開始時達成一致等。
加州大學洛杉磯分校（UCLA） 、Vanderbilt和加州大學伯克利分校（UC Berkeley） 分別用不同方法實現了時間同步。這3個實現都精確到子毫秒級，最初打算開發一個通用的、底層的時間同步組件，結果失敗了。應用程式需要一套多樣的時間同步，因此只能把時鐘作為一種服務來靈活地提供給用戶取捨使用。
某些情況允許逐漸的時間改變，但另一些則需要立即轉換成正確的時間。當時間同步改變下層時鐘時，會導致套用失敗。某些系統，例如NTP(Network Time Protocol)通過緩慢調整時鐘率同鄰節點同步來規避這個問題。NTP方案很容易在像TinyOS那樣對時間敏感的環境中出錯，因為時間即使早觸發幾毫秒都會引起無線信號或感測器數據丟失。
目前TinyOS採用的方案是提供獲取和設定當前系統時間的機制（TinyOS的通訊組件GenericComm使用hook函式為底層的通訊包打上時間戳，以實現精確的時間同步），同時靠套用來選擇何時激活同步。例如：在tinydb套用中，當一個節點監聽到來自於路由樹中父節點的時間戳訊息後會調整自己的時鐘以使下一個通訊周期的開始時間跟父節點一樣。它改變通訊間隔的睡眠周期持續時間而不是改變感測器的工作時間長度，因為減少工作周期會引起嚴重的服務問題，如數據獲取失敗。
J. Elson和D. Estrin給出了一種簡單實用的同步策略。其基本思想是，節點以自己的時鐘記錄事件，隨後用第三方廣播的基準時間加以校正，精度依賴於對這段間隔時間的測量。這種同步機制套用在確定來自不同節點的監測事件的先後關係時有足夠的精度。設計高精度的時鐘同步機制是感測網路設計和套用中的一個技術難點。
也有一些套用更重視健壯性而不是最精確的時間同步。例如：TinyDB只要求時間同步到毫秒級，但需要快速設定時間。在TinyDB中，簡單的，專用的抽象是種很自然的提供這種時間同步服務的方式，但是這種同步機制並不滿足所有需要的通用的時間同步。另外，還可以採取Lamport分散式同步算法，並不全部靠時鐘來同步。

1.4 任務通訊和同步

任務同步是在多任務的環境下存在的。因為多個任務彼此無關，並不知道有其它任務的存在，如果共享同一種資源就會存在資源競爭的問題。它主要解決原子操作和任務間相互合作的同步機制。
TinyOS中用nesC編譯器檢測共享變數有無衝突，並把檢測到的衝突語句放入原子操作或任務中來避免衝突（因為TinyOS的任務是串列執行的，任務之間不能互相搶占）。TinyOS單任務的模型避免了其他任務同步的問題。如果需要，可以參照傳統作業系統(例如μc/os)的方法，利用信號量來給多任務系統加上任務同步機制，使得提供的原子操作不是關掉所有的中斷，從而使得系統的回響不會延遲。
在TinyOS中，由於是單任務的系統，不同的任務來自不同的網路節點，因此採用管道的任務通信方式，也就是網路系統的通信方式。管道是無結構的固定大小數據流，但可以建立訊息信箱和訊息佇列來滿足結構數據的通信。

2 WSNOS記憶體管理

TinyOS的原始通訊使用緩衝區交換策略來進行記憶體管理。當網路包被收到，無線組件傳送一個緩衝區給套用；套用返回一個獨立的緩衝區給組件以備下一次接收。通訊棧中，管理緩衝區是很困難的。傳統的OS把複雜的緩衝區管理推給了核心處理，以拷貝複雜的存儲管理以及塊接口為代價，提供一個簡單的、無限制的用戶模式。AM[ Active Messages ]通訊模型不提供拷貝而且只提供非常簡單的存儲管理。訊息緩衝區數據結構是固定大小的。當TinyOS中的一個組件接收到一個訊息，它必須釋放一個緩衝區給無線棧。無線棧使用這個緩衝區來裝下一個到達的訊息。一般情況下，一個組件在緩衝區用完後會將其返回，但是如果這個組件希望保存這個緩衝區待以後用，會返回一個靜態地本地分配緩衝區，而不是依靠網路棧提供緩衝區的單跳通信接口。儘管只有1個組件，任何時候只有一個進入給定緩衝區的指針，組件來回交換使用它們。
靜態分配的記憶體有可預測性和可靠性高的優點，但缺乏靈活性。不是預估大了而造成浪費就是小了造成系統崩潰，為了充分利用記憶體，可以採用回響快的簡單的slab動態記憶體管理。

WSN通信

通訊協定是WSNOS研究的另一大重點。通訊協定的好壞不僅決定通訊功耗的大小，同時也影響到通訊的可靠性（包的丟失率，包過載等）。TinyOS為滿足這樣要求的通訊協定提供了基於輕量級AM通訊模型的最小的通訊核心。

1 AM通訊模型

介紹了這種輕量級的AM通訊模型，它構成TinyOS極小核心的通訊系統，其他套用都建立在這個通訊系統之上。AM訊息包含用戶級處理函式名稱和作為參數傳送的有效載荷，為了避免網路阻塞和保證充分的性能，訊息處理函式必須被很快地執行和異步處理。所有的這些措施都是為了實現低功耗的通訊。儘管AM源於大規模並行處理機和計算群集（Computing Cluster），但是一些基本概念也適用於資源受限的網路小設備。特別是輕量級的AM體系結構可作為槓桿來平衡擴展的通訊框架的需求和有效的靈活性。而且基於事件處理函式觸發模型，使套用級的開發者得以避免對數據的忙等，使系統能交迭地同其他活動通訊（如，同感測器互動或執行其它的套用）。

2 WSN通訊協定

介紹了AM為基礎的單跳協定和多跳協定，如S-MAC[ Sensor-MAC: Medium Access Control for Wireless Sensor Networks用於感測器網路的介質訪問控制]是其中一種單跳協定的低功耗實現；介紹了多跳通訊協定，主要解決自組織的網路路由。簡單介紹如下：
S-MAC基於RTS/CTS[ Request to send/Clear to Send請求傳送/清除傳送協定]調度，並返回無線訊息來減少監聽的開銷。S-MAC保持分段操作（split-phase）和無拷貝特性。所謂分段操作即：在TinyOS中由於任務之間不能互相占先執行，所以TinyOS沒有提供任何阻塞操作。為了讓一個耗時較長的操作儘快完成，一般來說都是將對這個操作的需求和這個操作的完成分開來實現，以便獲得較高的執行效率。
自組織（Ad hoc）的網路路由是一種不需要網橋（AP[ Access Point]）的無線對等傳輸模式。任兩個感測器若在彼此的通訊覆蓋範圍內，則這兩個感測器可直接互相通訊，共享資源。它具有對稱性，即B若在A的通訊範圍內，則A也在B的通訊範圍內；但往往由於某些外部條件的限制，可能會造成這種對稱的不協調。若在兩個相距較遠的感測器之間通訊，可以尋找一個中間的感測器作為轉發的節點，採用接力的方式來完成通訊過程。利用這種方式可以增加無線網路的通訊範圍，但隨著傳輸次數增加，數據的正確率會降低，傳輸過程的可靠性也降低。這種多跳路由一般可採用樹狀結構的集中，網路內部路由和分發（dissemination）3種形式。
比較普遍的是基於樹結構的路由。它包含父節點標識多跳數或從樹根開始的深度（即：父節點的多跳數加1）。一個節點傳送一個包給父節點，該節點再傳給其父節點，直到包到達樹根。設計的關鍵問題是怎樣建立路由樹和怎樣維護以及怎樣轉發以便提高傳輸的可靠性並降低功耗。主要用到兩種方法：鄰節點發現和連線質量估計服務；支持包的封裝和監視轉發。WSN系統中，基站連線到PC，發出廣播，接收到廣播的節點更新路由信息，並重新廣播給通過它自己可以連線到基站上的那些節點。這些節點記住第一次監聽到的路由更新，就是相應的到基站的最短路徑。為了防止路由循環，時間被分成多個時間段，每個時間段路由更新廣播一次。

3 低功耗監聽協定

針對能量消耗，有以下四個特點：（1）主機模組MCU[ Micro-Controller Unit 微處理器]和收發模組占據電源消耗的絕大部分比重；（2）Active（激活）狀態耗能最多，相對而言Idle（休眠）狀態耗能最少；（3）收發模組比MCU耗能要多很多。傳送一個位元組（byte）消耗的能量約等於11000個MCU計算周期所消耗的能量，或是收發一位（bit）消耗的能量相當於MCU處理100條指令；從總體的消耗來看，收發數據所消耗的能量也是最多的。如果我們能夠讓收發模組和MCU處於多數時間休眠，少數時間激活狀態，那么就能明顯地降低系統的總體功耗。
介紹了兩種典型的低功耗監聽方式：周期性多跳監聽（Periodic Multi-Hop Listening）和低功耗監聽（Low Power Listening）。巨觀上進行周期性多跳監聽，設定周期性採樣的時間間隔來減少主機和通訊模組的激活工作時間，例如：每100秒激活10秒，則減少了90%的能耗，但是限制了實際的頻寬；微觀上進行低功耗監聽，增加監聽頻率，把每100秒監聽10秒變成每300微秒監聽30微秒，這樣可以在監聽不到任何信息的時候讓無線收發器處於休眠狀態，並且能夠在傳送1/3位信息的時間內喚醒，但是需要額外花費傳送5位信息的時間來檢測信息的有無。
使用以上兩種監聽方式帶來的降低功耗效果是顯著的。兩者都不採用時MCU和收發模組的功耗都很大；只採用微觀的低功耗監聽，MCU的功耗明顯降低，但是，收發模組的功耗降低不是很顯著；只採用巨觀的周期性多跳監聽，MCU和收發模組的功耗都顯著降低；兩者都採用，MCU的功耗幾乎為0，收發模組功耗顯著降低。可以用電池壽命數據來說明使用了以上兩種監聽方式帶來的低功耗的效果。兩者都不採用時電池只能使用3天；只採用微觀的低功耗監聽，電池可以使用6.54天；只採用巨觀的周期性多跳監聽，電池壽命明顯增加至65天；兩者都採用，電池壽命可以達到數年。可見，採用這兩種監聽方式把電池的壽命從3天延長到幾年，對於套用來說是具有突破性意義的。Intel的下一代Mote原型便採用這種策略來使得整個系統維持操作任務周期不超過1%。