【正文】 儲(chǔ)資源少的限制，這能夠讓 TinyOS 很有效的運(yùn)行在無(wú)線傳感器網(wǎng)絡(luò)上并去執(zhí)行相應(yīng)的管理工作等。TinyOS 本身提供了一系列的組件，可以很簡(jiǎn)單方便的編制程序，用來(lái)獲取和處理傳感器的數(shù)據(jù)并通過(guò)無(wú)線電來(lái)傳輸信息。可以把 TinyOS 看成是一個(gè)可以與傳感器進(jìn)行交互的 API 接口，它們之間可以進(jìn)行各種通訊。TinyOS 在構(gòu)建無(wú)線傳感器網(wǎng)絡(luò)時(shí)，它會(huì)有一個(gè)基地控制臺(tái)，主要是用來(lái)控制各個(gè)傳感器子節(jié)點(diǎn)，并聚集和處理它們所采集到的信息。TinyOS 只要在控制臺(tái)發(fā)出管理信息，然后由各個(gè)節(jié)點(diǎn)通過(guò)無(wú)線網(wǎng)絡(luò)互相傳遞，最后達(dá)到協(xié)同一致的目的，非常方便。 TinyOS 框架圖 21是 TinyOS 的總體框架。物理層硬件為框架的最底層，傳感器、收發(fā)器以及時(shí)鐘等硬件能觸發(fā)事件的發(fā)生，交由上層處理。相對(duì)下層的組件也能觸發(fā)事件交由上層處理。而上層會(huì)發(fā)出命令給下層處理。為了協(xié)調(diào)各個(gè)組件任務(wù)的有序處理，需要操作系統(tǒng)采取一定的調(diào)度機(jī)制。圖 22提供了 TinyOS 組件的所包括的具體內(nèi)容，包括一組命令處理函數(shù)，一組事件處理函數(shù)，一組任務(wù)集合和一個(gè)描述狀態(tài)信息和固定數(shù)據(jù)結(jié)構(gòu)的框架。除了 TinyOS 提供的處理器初始化、系統(tǒng)調(diào)度和 C 運(yùn)行時(shí)庫(kù)（C RunTime）3 個(gè)組件是必需的以外，每個(gè)應(yīng)用程序可以非常靈活地使用任何 TinyOS 組件。圖 21TinyOS 的總體框架示意圖這種面向組件的系統(tǒng)框架的優(yōu)點(diǎn)是：首先，“事件命令任務(wù)”的組件模型可以屏蔽低層細(xì)節(jié)，有利于程序員更方便地編寫應(yīng)用程序；其次，“命令事件”的雙向信息控制機(jī)制，使得系統(tǒng)的實(shí)現(xiàn)更加靈活；再次，調(diào)度機(jī)制獨(dú)立成單獨(dú)的一塊，有利于為了滿足不同調(diào)度需求進(jìn)行的修改和升級(jí)。圖 22 TinyOS 組件的功能模塊 TinyOS 內(nèi)核 調(diào)度機(jī)制TinyOS 的調(diào)度模型為任務(wù)加事件的兩級(jí)調(diào)度，調(diào)度的方式是任務(wù)不搶占事件要搶占，調(diào)度的算法是簡(jiǎn)單的 FIFO，任務(wù)隊(duì)列是功耗敏感的。調(diào)度模型有以下的特點(diǎn)：（1）基本的任務(wù)單線程運(yùn)行到結(jié)束，只分配單個(gè)任務(wù)棧，這對(duì)內(nèi)存受限的系統(tǒng)很重要。（2）FIFO 的任務(wù)調(diào)度策略是電源敏感的。當(dāng)任務(wù)隊(duì)列為空，處理器休眠，等待事件發(fā)生來(lái)觸發(fā)調(diào)度。（3）兩級(jí)的調(diào)度結(jié)構(gòu)可以實(shí)現(xiàn)優(yōu)先執(zhí)行少量同事件相關(guān)的處理，同時(shí)打斷長(zhǎng)時(shí)間運(yùn)行的任務(wù)。（4）基于事件的調(diào)度策略，只需少量空間就可獲得并發(fā)性，并允許獨(dú)立的組件共享單個(gè)執(zhí)行上下文。同事件相關(guān)的任務(wù)集合可以很快被處理，不允許阻塞，具有高度并發(fā)性。TinyOS 只是搭建好了最基本的調(diào)度框架，只實(shí)現(xiàn)了軟實(shí)時(shí)，而無(wú)法滿足硬實(shí)時(shí)，這對(duì)嵌入式系統(tǒng)的可靠性會(huì)產(chǎn)生影響。同時(shí)，由于是單任務(wù)的內(nèi)核，吞吐量和處理器利用率不高，因此有可能需要設(shè)計(jì)多任務(wù)系統(tǒng)。為保證系統(tǒng)的實(shí)時(shí)性，多采用基于優(yōu)先級(jí)的可搶占式的任務(wù)調(diào)度策略。依賴于應(yīng)用需求，出現(xiàn)了許多基于優(yōu)先級(jí)多任務(wù)的調(diào)度算法的研究。[50]把 TinyOS 擴(kuò)展成多任務(wù)的調(diào)度，給 TinyOS 加入了多任務(wù)的調(diào)度功能，提高了系統(tǒng)的響應(yīng)速度。[51]提出在 TinyOS 中實(shí)現(xiàn)基于時(shí)限（deadline）的優(yōu)先級(jí)調(diào)度，有利于提高 WSN 系統(tǒng)的實(shí)時(shí)性。[52]提出了一種任務(wù)優(yōu)先級(jí)調(diào)度算法來(lái)相對(duì)提高過(guò)載節(jié)點(diǎn)的吞吐量以解決本地節(jié)點(diǎn)包過(guò)載的問(wèn)題。總之，調(diào)度決定了處理器的功耗，如 TinyDB 就是使用好的調(diào)度策略來(lái)降低功耗的。更為重要的是，各種調(diào)度算法也能更好地提高處理器的響應(yīng)速度，從而提高系統(tǒng)的可靠性。各種基于 TinyOS 調(diào)度算法的擴(kuò)展研究，各自獨(dú)立地使得高可靠性和低功耗分別得到滿足。在 TinyOS 中，代碼運(yùn)行方式為響應(yīng)中斷的異步處理或同步地調(diào)度任務(wù)。TinyOS 的每一個(gè)應(yīng)用代碼里，約有 41%64%的中斷代碼[53]，可見中斷的優(yōu)化處理非常重要。對(duì)于低功耗的處理而言，需要長(zhǎng)時(shí)間休眠，可以通過(guò)減少中斷的開銷來(lái)降低喚醒處理器的功耗。目前通過(guò)禁用和打開中斷來(lái)實(shí)現(xiàn)原子操作，這個(gè)操作非常的短暫（幾個(gè)時(shí)鐘周期cycles）。然而，讓中斷關(guān)掉很長(zhǎng)時(shí)間會(huì)延遲中斷的處理，造成系統(tǒng)反應(yīng)遲鈍。TinyOS 的原子操作能工作得很好是因?yàn)樗柚沽俗枞氖褂靡蚕拗屏嗽硬僮鞔a段的長(zhǎng)度，而這一些條件的滿足是通過(guò) nesC[53]編譯器來(lái)協(xié)助處理的。由于 nesC 編譯器對(duì) TinyOS 做靜態(tài)的資源分析以及其調(diào)度模式?jīng)Q定了中斷不允許嵌套。在多任務(wù)模式下，中斷嵌套可以提高實(shí)時(shí)響應(yīng)速度。 時(shí)鐘同步TinyOS 提供獲取和設(shè)置當(dāng)前系統(tǒng)時(shí)間的機(jī)制，同時(shí)，在 WSN 網(wǎng)絡(luò)中提供分布式的時(shí)間同步。TinyOS 是以通訊為中心的操作系統(tǒng)，因此更加注重各個(gè)節(jié)點(diǎn)的時(shí)間同步。如：傳感器融合應(yīng)用程序收集一組從不同地方讀來(lái)的信息（如：較短距離位置需要建立暫時(shí)一致的數(shù)據(jù)）；TDMA 風(fēng)格的介質(zhì)訪問(wèn)協(xié)議需要精確的時(shí)間同步；電源敏感的通訊調(diào)度需要發(fā)送者和接收者在他們的無(wú)線信號(hào)開始時(shí)達(dá)成一致等。加州大學(xué)洛杉磯分校（UCLA）[54] 、Vanderbilt[55]和加州大學(xué)伯克利分校（UCBerkeley）[56]分別用不同方法實(shí)現(xiàn)了時(shí)間同步。這 3 個(gè)實(shí)現(xiàn)都精確到子毫秒級(jí)，最初打算開發(fā)一個(gè)通用的、底層的時(shí)間同步組件，結(jié)果失敗了。應(yīng)用程序需要一套多樣的時(shí)間同步，因此只能把時(shí)鐘作為一種服務(wù)來(lái)靈活地提供給用戶取舍使用。某些情況允許逐漸的時(shí)間改變，但另一些則需要立即轉(zhuǎn)換成正確的時(shí)間。當(dāng)時(shí)間同步改變下層時(shí)鐘時(shí)，會(huì)導(dǎo)致應(yīng)用失敗。某些系統(tǒng)，例如 NTP(network timeprotocol)通過(guò)緩慢調(diào)整時(shí)鐘率同鄰節(jié)點(diǎn)同步來(lái)規(guī)避這個(gè)問(wèn)題。NTP 方案很容易在像 TinyOS 那樣對(duì)時(shí)間敏感的環(huán)境中出錯(cuò)，因?yàn)闀r(shí)間即使早觸發(fā)幾毫秒都會(huì)引起無(wú)線信號(hào)或傳感器數(shù)據(jù)丟失。目前 TinyOS 采用的方案是提供獲取和設(shè)置當(dāng)前系統(tǒng)時(shí)間的機(jī)制（TinyOS 的通訊組件 GenericComm 使用 hook 函數(shù)為底層的通訊包打上時(shí)間戳，以實(shí)現(xiàn)精確的時(shí)間同步[57]），同時(shí)靠應(yīng)用來(lái)選擇何時(shí)激活同步。例如：在 TinyDB 應(yīng)用中，當(dāng)一個(gè)節(jié)點(diǎn)監(jiān)聽到來(lái)自于路由樹中父節(jié)點(diǎn)的時(shí)間戳消息后會(huì)調(diào)整自己的時(shí)鐘以使下一個(gè)通訊周期的開始時(shí)間跟父節(jié)點(diǎn)一樣。它改變通訊間隔的睡眠周期持續(xù)時(shí)間而不是改變傳感器的工作時(shí)間長(zhǎng)度，因?yàn)闇p少工作周期會(huì)引起嚴(yán)重的服務(wù)問(wèn)題，如數(shù)據(jù)獲取失敗。節(jié)點(diǎn)以自己的時(shí)鐘記錄事件，隨后用第三方廣播的基準(zhǔn)時(shí)間加以校正，精度依賴于對(duì)這段間隔時(shí)間的測(cè)量。這種同步機(jī)制應(yīng)用在確定來(lái)自不同節(jié)點(diǎn)的監(jiān)測(cè)事件的先后關(guān)系時(shí)有足夠的精度。設(shè)計(jì)高精度的時(shí)鐘同步機(jī)制是傳感網(wǎng)絡(luò)設(shè)計(jì)和應(yīng)用中的一個(gè)技術(shù)難點(diǎn)。也有一些應(yīng)用更重視健壯性而不是最精確的時(shí)間同步。例如：TinyDB 只要求時(shí)間同步到毫秒級(jí)，但需要快速設(shè)置時(shí)間。在 TinyDB 中，簡(jiǎn)單的，專用的抽象是種很自然的提供這種時(shí)間同步服務(wù)的方式，但是這種同步機(jī)制并不滿足所有需要的通用的時(shí)間同步。另外，還可以采取 Lamport 分布式同步算法，并不全部靠時(shí)鐘來(lái)同步。 任務(wù)通訊和同步任務(wù)同步是在多任務(wù)的環(huán)境下存在的。因?yàn)槎鄠€(gè)任務(wù)彼此無(wú)關(guān)，并不知道有其它任務(wù)的存在，如果共享同一種資源就會(huì)存在資源競(jìng)爭(zhēng)的問(wèn)題。它主要解決原子操作和任務(wù)間相互合作的同步機(jī)制。TinyOS 中用 nesC 編譯器檢測(cè)共享變量有無(wú)沖突，并把檢測(cè)到的沖突語(yǔ)句放入原子操作或任務(wù)中來(lái)避免沖突（因?yàn)?TinyOS 的任務(wù)是串行執(zhí)行的，任務(wù)之間不能互相搶占）。TinyOS 單任務(wù)的模型避免了其他任務(wù)同步的問(wèn)題。如果需要，可以參照傳統(tǒng)操作系統(tǒng)(例如 μc/os)的方法，利用信號(hào)量來(lái)給多任務(wù)系統(tǒng)加上任務(wù)同步機(jī)制，使得提供的原子操作不是關(guān)掉所有的中斷，從而使得系統(tǒng)的響應(yīng)不會(huì)延遲。在 TinyOS 中，由于是單任務(wù)的系統(tǒng)，不同的任務(wù)來(lái)自不同的網(wǎng)絡(luò)節(jié)點(diǎn)，因此采用管道的任務(wù)通信方式，也就是網(wǎng)絡(luò)系統(tǒng)的通信方式。管道是無(wú)結(jié)構(gòu)的固定大小數(shù)據(jù)流，但可以建立消息郵箱和消息隊(duì)列來(lái)滿足結(jié)構(gòu)數(shù)據(jù)的通信。 TinyOS 內(nèi)存管理TinyOS 的原始通訊使用緩沖區(qū)交換策略來(lái)進(jìn)行內(nèi)存管理。當(dāng)網(wǎng)絡(luò)包被收到，無(wú)線組件傳送一個(gè)緩沖區(qū)給應(yīng)用；應(yīng)用返回一個(gè)獨(dú)立的緩沖區(qū)給組件以備下一次接收。通訊棧中管理緩沖區(qū)是很困難的。傳統(tǒng)的 OS 把復(fù)雜的緩沖區(qū)管理推給了內(nèi)核處理，以拷貝復(fù)雜的存儲(chǔ)管理以及塊接口為代價(jià)，提供一個(gè)簡(jiǎn)單的、無(wú)限制的用戶模式。AM 通訊模型不提供拷貝而且只提供非常簡(jiǎn)單的存儲(chǔ)管理。消息緩沖區(qū)數(shù)據(jù)結(jié)構(gòu)是固定大小的。當(dāng) TinyOS 中的一個(gè)組件接收到一個(gè)消息，它必須釋放一個(gè)緩沖區(qū)給無(wú)線棧。無(wú)線棧使用這個(gè)緩沖區(qū)來(lái)裝下一個(gè)到達(dá)的消息。一般情況下，一個(gè)組件在緩沖區(qū)用完后會(huì)將其返回，但是如果這個(gè)組件希望保存這個(gè)緩沖區(qū)待以后用，會(huì)返回一個(gè)靜態(tài)地本地分配緩沖區(qū)，而不是依靠網(wǎng)絡(luò)棧提供緩沖區(qū)的單跳通信接口。盡管只有 1 個(gè)組件，任何時(shí)候只有一個(gè)進(jìn)入給定緩沖區(qū)的指針，組件來(lái)回交換使用它們。靜態(tài)分配的內(nèi)存有可預(yù)測(cè)性和可靠性高的優(yōu)點(diǎn)，但缺乏靈活性。不是預(yù)估大了而造成浪費(fèi)就是小了造成系統(tǒng)崩潰，為了充分利用內(nèi)存，可以采用響應(yīng)快的簡(jiǎn)單的 slab 動(dòng)態(tài)內(nèi)存管理。 通訊通訊協(xié)議是 WSNs 研究的另一大重點(diǎn)。通訊協(xié)議的好壞不僅決定通訊功耗的大小，同時(shí)也影響到通訊的可靠性（包的丟失率，包過(guò)載等）。TinyOS 為滿足這樣要求的通訊協(xié)議提供了基于輕量級(jí) AM 通訊模型的最小的通訊內(nèi)核。 AM 通訊模型輕量級(jí)的AM通訊模型，它構(gòu)成TinyOS極小內(nèi)核的通訊系統(tǒng)，其他應(yīng)用都建立在這個(gè)通訊系統(tǒng)之上。AM 消息包含用戶級(jí)處理函數(shù)名稱和作為參數(shù)傳送的有效載荷，為了避免網(wǎng)絡(luò)阻塞和保證充分的性能，消息處理函數(shù)必須被很快地執(zhí)行和異步處理。所有的這些措施都是為了實(shí)現(xiàn)低功耗的通訊。盡管 AM 源于大規(guī)模并行處理機(jī)和計(jì)算群集（Computing Cluster），但是一些基本概念也適用于資源受限的網(wǎng)絡(luò)小設(shè)備。特別是輕量級(jí)的 AM 體系結(jié)構(gòu)可作為杠桿來(lái)平衡擴(kuò)展的通訊框架的需求和有效的靈活性。而且基于事件處理函數(shù)觸發(fā)模訊（例如，同傳感器交互或執(zhí)行其它的應(yīng)用）。 WSN 通訊協(xié)議AM 為基礎(chǔ)的單跳協(xié)議和多跳協(xié)議，如 SMAC是其中一種單跳協(xié)議的低功耗實(shí)現(xiàn)；多跳通訊協(xié)議，主要解決自組織的網(wǎng)絡(luò)路由。簡(jiǎn)單介紹如下：SMAC 基于 RTS/CTS 調(diào)度，并返回?zé)o線消息來(lái)減少監(jiān)聽的開銷。SMAC 保持分段操作（splitphase）和無(wú)拷貝特性。所謂分段操作即：在 TinyOS 中由于任務(wù)之間不能互相占先執(zhí)行，所以 TinyOS 沒(méi)有提供任何阻塞操作。為了讓一個(gè)耗時(shí)較長(zhǎng)的操作盡快完成，一般來(lái)說(shuō)都是將對(duì)這個(gè)操作的需求和這個(gè)操作的完成分開來(lái)實(shí)現(xiàn)，以便獲得較高的執(zhí)行效率。自組織（Ad hoc）的網(wǎng)絡(luò)路由是一種不需要網(wǎng)橋（AP）的無(wú)線對(duì)等傳輸模式。任兩個(gè)傳感器若在彼此的通訊覆蓋范圍內(nèi)，則這兩個(gè)傳感器可直接互相通訊，共享資源。它具有對(duì)稱性，即 B 若在 A 的通訊范圍內(nèi)，則 A 也在 B 的通訊范圍內(nèi)；但往往由于某些外部條件的限制，可能會(huì)造成這種對(duì)稱的不協(xié)調(diào)。若在兩個(gè)相距較遠(yuǎn)的傳感器之間通訊，可以尋找一個(gè)中間的傳感器作為轉(zhuǎn)發(fā)的節(jié)點(diǎn)，采用接力的方式來(lái)完成通訊過(guò)程。利用這種方式可以增加無(wú)線網(wǎng)絡(luò)的通訊范圍，但隨著傳輸次數(shù)增加，數(shù)據(jù)的正確率會(huì)降低，傳輸過(guò)程的可靠性也降低。這種多跳路由一般可采用樹狀結(jié)構(gòu)的集中，網(wǎng)絡(luò)內(nèi)部路由和分發(fā)（dissemination）3 種形式。比較普遍的是基于樹結(jié)構(gòu)的路由。它包含父節(jié)點(diǎn)標(biāo)識(shí)多跳數(shù)或從樹根開始的深度（即：父節(jié)點(diǎn)的多跳數(shù)加 1）。一個(gè)節(jié)點(diǎn)傳送一個(gè)包給父節(jié)點(diǎn)，該節(jié)點(diǎn)再傳給其父節(jié)點(diǎn)，直到包到達(dá)樹根。設(shè)計(jì)的關(guān)鍵問(wèn)題是怎樣建立路由樹和怎樣維護(hù)以及怎樣轉(zhuǎn)發(fā)以便提高傳輸?shù)目煽啃圆⒔档凸?。主要用到兩種方法：鄰節(jié)點(diǎn)發(fā)現(xiàn)和連接質(zhì)量估計(jì)服務(wù)；支持包的封裝和監(jiān)視轉(zhuǎn)發(fā)。WSN 系統(tǒng)中，基站連接到PC，發(fā)出廣播，接收到廣播的節(jié)點(diǎn)更新路由信息，并重新廣播給通過(guò)它自己可以連接到基站上的那些節(jié)點(diǎn)。這些節(jié)點(diǎn)記住第一次監(jiān)聽到的路由更新，就是相應(yīng)的到基站的最短路徑。為了防止路由循環(huán)，時(shí)間被分成多個(gè)時(shí)間段，每個(gè)時(shí)間段路由更新廣播一次。 低功耗監(jiān)聽協(xié)議（1）主機(jī)模塊 MCU 和收發(fā)模塊占據(jù)電源消耗的絕大部分比重；（2）Active（激活）狀態(tài)耗能最多，相對(duì)而言 Idle（休眠）狀態(tài)耗能最少；（3）收發(fā)模塊比 MCU 耗能要多很多。發(fā)送一個(gè)字節(jié)（byte）消耗的能量約等于 11000個(gè) MCU 計(jì)算周期所消耗的能量[69]，或是收發(fā)一位（bit）消耗的能量相當(dāng)于 MCU處理 100 條指令；從總體的消耗來(lái)看，收發(fā)數(shù)據(jù)所消耗的能量也是最多的。如果我們能夠讓收發(fā)模塊和 MCU 處于多數(shù)時(shí)間休眠，少數(shù)時(shí)間激活狀態(tài)，那么就能明顯地降低系統(tǒng)的總體功耗。兩種典型的低功耗監(jiān)聽方式：周期性多跳監(jiān)聽（PeriodicMultiHop Listening）和低功耗監(jiān)聽（Low Power Listening）。宏觀上進(jìn)行周期性多跳監(jiān)聽，設(shè)置周期性采樣的時(shí)間間隔來(lái)減少主機(jī)和通訊模塊的激活工作時(shí)間，例如：每 100 秒激活 10 秒，則減少了 90%的能耗，但是限制了實(shí)際的帶寬；微觀上進(jìn)行低功耗監(jiān)聽，增加監(jiān)聽頻率，把每 100 秒監(jiān)聽 10 秒變成每 300微秒監(jiān)聽 30 微秒，這樣可以在監(jiān)聽不到任何信息的時(shí)候讓無(wú)線收發(fā)器處于休眠狀態(tài)，并且能夠在傳送 1/3 位信息的時(shí)間內(nèi)喚醒，但是需要額外花費(fèi)傳送 5 位信息的時(shí)間來(lái)檢測(cè)信息的有無(wú)。使用以上兩種監(jiān)聽方式帶來(lái)的降低功耗效果是顯著的。在[69]中作了詳細(xì)的比較，兩者都不采用時(shí) MCU 和收發(fā)模塊的功耗都很大；只采用微觀的低功耗監(jiān)聽，MCU 的功耗明顯降低，但是，收發(fā)模塊的功耗降低不是很顯著；只采用宏觀的周期性多跳監(jiān)聽，MCU 和收發(fā)模塊的功耗都顯著降低；兩者都采用，MCU 的功耗幾乎為 0，收發(fā)模塊功耗顯著降低?？梢杂秒姵貕勖鼣?shù)據(jù)來(lái)說(shuō)明使用了以上兩種監(jiān)聽方式帶來(lái)的低功耗的效果。兩者都不采用時(shí)電池只能使用 3 天；只采用微觀的低功耗監(jiān)聽，電池可以使用 天；只采用宏觀的周期性多跳監(jiān)聽，電池壽命明顯增加至 65 天；兩者都采用，電池壽命可以達(dá)到數(shù)年?？梢?，采用這兩種監(jiān)聽方式把電池的壽命從 3 天延長(zhǎng)到幾年，對(duì)于應(yīng)用來(lái)說(shuō)是具有突破性意義的。Intel 的下一代 Mote 原型[38]便采用這種策略來(lái)使得整個(gè)系統(tǒng)維持操作任務(wù)周期不超過(guò) 1%。 電源管理服務(wù)所謂服務(wù)就是提