Starfish -- 基於策略的WSN網絡自治系統

嗯，看了一段時間的WSN網絡管理，國內的文章基本都是籠統的提出一個框架，具體系統呢……沒有。國外的要好不少，Manna這種開創式的架構沒有實現情有可原，前兩天看到一個帝國理工作的Starfish WSN^[1]（2010）網絡管理系統，感受不錯，這裏總結一下做爲之後的參考。

Starfish 基於策略……這裏的策略是什麼？相似於專家系統中的rules，就是有一些前提條件，當知足條件時去執行一些動做。爲何要搞一個這種中間件出來？直接使用HARD-CODE + 條件判斷不就好了？嗯，乍看起來是差很少，但仔細想一想HARD-CODE的可拓展性實在是不好……當要加入新的策略時須要從新燒錄節點（在不能動態加載二進制模塊的前提下），改變策略對系統形成的開銷實在太大。而且不方便網絡管理員對網絡進行管理，畢竟咱們不能強求全部人都要進行嵌入式編程吧……使用中間件的形式使咱們能夠在語言的層次多一層抽象，使網絡管理員使用相似腳本形式的語言（甚至是圖形化的界面）就能夠對網絡進行管理。固然多一層抽象會多一層運行時開銷以及解釋程序也一樣須要佔用一些資源……但經過仔細的設計，這些複雜度與其帶來的好處相比，嗯，微不足道！

嗯，Starfish由三大部分組成：（1）Finger2 policy system，由ponder2優化而來；（2）module library，嗯，就是與policy 直接交互的那一層，HARD-CODE，在編譯policy代碼時決定具體加載哪些module；（3）一個圖形化的編程工具用於編寫policy，這個GUI能夠沒有，但工具必定要有。很好，這個架構很明晰！尤爲是module的引入以及編譯時對module的選擇。哦，差點忘了說爲何管理或稱爲policy腳本還須要編譯，由於在WSN網絡上直接傳輸腳本string……數據量比較大，先編譯成字節碼以減小網絡開銷，也方便解釋器進行解釋（有一部分工做交給編譯器作就好了）。其中policy system 與module library 要運行在節點之上，須要特別優化與設計。

先扯扯Finger2 policy system，整個系統的關鍵就在於這裏。

圖-1 Finger2 架構

圖-1展示了Finger2 的基本架構，其中粗的實黑線表明執行流程，嗯，有兩個起始點；細實黑線表明不一樣模塊間的接口；虛線表明數據的引用。Eg：有一個來自網絡的請求進入節點，首先經過認證模塊（嗯，應該只是記錄權限等級）；然後進入事件管理模塊，事件管理模塊去查詢對應的policies庫中有無請求調用的policy，若是有，將其放入VM中執行；執行時先根據當前任務所具備的權限等級（前面已經記錄）判別每一步動做是否能夠被執行，如可，調用module中的functions執行之。

很明顯的一點Finger2 中包含一個VM，涉及到VM確定就有相應的編程語言，固然在這裏能夠稱之爲策略式語言……固然不能很複雜……主要緣由是咱們能力有限，複雜了無法整……固然還由於解釋器運行在node中，語言複雜了，解釋器相應的可能會變得複雜，node可承受不起。因此要實現這麼一個系統，研究編譯器與解釋器和程序設計語言確定是少不了了，不過不要緊，有的是參考。ponder2就是一個現成的，若是以爲太難，TinyOS的NESCC也能夠提供素材，隱約記得Levis也寫過一個運行在節點上的解釋器（P. Levis and D. Culler. Mate: A tiny virtual machine for sensor networks. ACM SIGARCH Computer Architecture News, 30(5):95, 2002.），不知道Finger2 開源沒……

再注意到「Auth Manager」，一般來講全部的遠程動做都應該通過此模塊，嗯，會影響效率嗎？關鍵要看怎麼實現。如今這部分還不是主要內容（在實際使用中很重要），先Pass過去，但要預留好足夠的拓展性。

最後談談policy的分發問題。經過上面的論述能夠看出policy是依靠於module中的Functions來執行實際的內容的，policy是能夠動態裝載運行的，但module是HARD-CODE（用c或其餘程序設計語言編寫）在節點之中的，這也就決定了一個節點無法運行全部的policy，其可扮演的role是有限制的。在編譯節點對應的policy時就應該作這樣的可行性檢測，不要到運行時才發現其不能執行相應的policy，浪費傳輸的能量與帶寬！那policy應該存放於節點的什麼地方呢？RAM？ROM？其實均可以，編譯後policy的大小應該不大，但若是一個節點中有太多的policy則放置於ROM中是合理的選擇，但這樣作會增長存儲與調用時的時間開銷，因此Keep it simple，一個節點別作太多事……

具體細節無法講太多，能夠看看原文，哦，最後看一個policy的例子。前兩個policy均是由一些條件觸發的on something；而第三個是Authorise policy，有subject與target，當發送者與目標知足條件時觸發此policy。

def ECG request 
    on gui.RequestUpdate(patient, type) 
    if network.IsAvail(patient) and type is ECG 
    do patient.policy.Install(ECG update) 
On request from the nurse of an ECG update for a 
patient, install mission ‘ECG update’ on the patient’s 
endpoint. 
def ECG update 
    on sensor.Reading(type, value) 
    if type is ECG 
    do network.Send(nurse, value, timer.Now()) 
On receiving of an ECG reading transmit it over the 
network to the nurse along with a local timestamp. 
def allow nurse policy install+ 
    subject nurse 
    target patient 
    if power.Level() > 20 and nurse.type is staff nurse 
    action policy.Install 
Authorise access of ‘policy.Install()’ to a staff nurse 
given that the local power level is above 20%.

下面就是module library的設計。

不得不說這一部分是系統中最難設計的，如同C庫和STL的設計同樣。哪些是必須提供的，哪些是可選的……嗯，咱們要研究（老張的口氣）一下……且看一下Starfish中定義了哪些在Fundamental modules中。

既然稱之爲WSN，那麼sensor module天然不能少，但現實中sensor那麼多怎麼樣作到拓展性更好呢？新寶的研究提供了另外一種可能性，不過這裏咱們不作過多的介入。Ok，Sensor Module要提供一組通用接口以便每種傳感器都能使用，嗯，Starfish中有兩個：「Sense」「Get」。Sense 的功能是週期性的採集傳感器信息；Get 是異步的（當即）採集傳感器信息。具體的實現方式則留給Module 設計者來解決了，嗯，看兩個實際policy 的例子。

def Initialize 
    on boot.Done() 
    if sensor.IsOk(temp) 
    do sensor.Sense(temp, 250), 
        buffer.Create(temp, 50) 
On boot-up set the temperature sensor to read 
every 250ms and create a buffer of size 50 for readings.  
def StoreTemperature 
    on sensor.Reading(type, value) 
    if type is temp 
    do buffer.Add(type, value) 
On receiving an event from the temperature sensor 
and store it in the buffer.  
def SendAvgTemp 
    on buffer.Full(type) 
    if type is temp and network.IsAvail(tempGtor) 
    do network.Send(tempGtor, tempUpdate, 
        feature.Avg(buffer.Get(type))) 
When the buffer is full, send the average temperature 
over the network to node ‘tempGtor’.

能夠看見policy中的sensor、buffer、network以及feature就是一個個的module，嗯，不錯……

Buffer module，不錯，Starfish 也將buffer 做爲一個module來實現了。這個還真的要有，其餘module確定有使用buffer的需求的，好比求平均，取最小值等操做。但咱們的設計中可不能夠不侷限於buffer，想一想STL中的容器還有做用在其上的操做……嗯，有搞頭。以此推廣開來，實現一個簡化版本的STL也何嘗不可…… >_<||| 又扯遠了……

Arithmetic Association Logical operator.這個加上上面的Buffer不就是簡化版的STL嗎……

Timers，這個也是必須有的。你好比說週期性操做，延時操做都須要timer的，至於絕對時間的肯定，嗯，只能使用網絡進行同步。Starfish Module Library（SML）中timers提供的功能有：Periodic 和OneShot。

固然，Network Module 怎麼能少呢？將底層與操做系統直接交互的部分做封裝，只關心應用層的內容！既然咱們的研究基於IP，單播、廣播、組播都是必須的咯；固然接收端要有Receive event能夠觸發，使用觀察者模式註冊偵聽；檢測連通性的函數也必需要能提供。

固然爲了測試須要，Serial Module也是必須的，基本的兩個函數「Send」「Receive」（異步Event形式）就足夠了。

PS：

爲何系統中有Network、timer等等API，還須要從新加一層包裝？嗯，要知道，在Policy系統運行的Action只能調用Module Library中的function，不將系統中的功能包一層新皮，怎麼用呢？難道再作一個Native接口？這就很不合理了，Policy與Native function的接口就是Module！

Module Library 怎麼管理？嗯，確實，當一個policy 調用一個module 的時候咱們怎不能花大把時間去尋找這個module的位置吧……原文中沒說，那該腫麼辦呢？OSGI中是怎麼組織bundle的？嗯……明白了。

好了，這麼多Policy管理起來也是一個問題。

嗯，我腦中忽然閃現一個名詞「OSGI」，很好的開源參考資料嗎！原來我作的這麼多事都是有意義的，都是融匯貫通的，必須的！Starfish中的Policy 管理與OSGI很相像，Install、Remove、Enable和Disable四種基本操做。

爲了管理方便，Starfish 又引入missions 的概念，將一組policies 組合成一個mission，使用與之對應的mission管理方法。

嗯，關於Module 的拓展與編寫Module。

開發Module 的人員應該只關注三個接口：EventSourceI（能夠接受一大批的觀察者），PredicateI（同步執行操做Block 直到執行完畢），ActionI（異步執行操做當即返回）。固然，名字能夠不一樣，上面只是接口的種類……Module中能夠存在上述三種接口。應該提供簡便的方法來輔助Module 編程，嗯，最好仍是使用純粹的C形式，使用Makefile加上通用架構文件來簡化編程的複雜度，就像Linux 中開發驅動程序同樣。

最後就是Policy 編程工具了。

嗯，就像前文中所說的Policy 是交由網絡管理員來制定的，總不能讓全部網絡管理員都學習嵌入式編程吧……因而乎提供一個簡便的Policy 設計工具很是必要。Starfish提供的是一個帶GUI的設計工具，咱們先不用GUI了，先把Policy 編譯器設計出來再說吧……

引入三個概念：「Missions」、「Roles」和「Configurations」。

先對這三個概念進行一下說明。

首先是Missions 與Roles。missions 是一組policies 的集合，包括policies 自己和它們之間的關係和執行順序，但policies之間的關係不用中間件去操心，這部分在編譯期間就已經處理完畢。Roles 是實現Missions 與policies 和節點解耦的關鍵概念，Starfish 中將missions 和 policies與Roles 進行對應（感受能夠是多對多）而不是與實際節點，這樣每一個節點所扮演的角色就能夠轉換，也能夠扮演多重角色（固然確定有些角色之間是互斥的關係）。固然須要注意的是因爲每一個節點在燒錄時載入的modules 是有限與固定的，是故決定了每一個節點所能扮演的角色也是有限的，其所能加載的Missions 和policies 也是有限的。最後，當節點決定扮演一個Role 時就會激活一些Missions 和 Policies；其卸去一個角色的同時，也會使相應的一些Mission 和Policies 失效，這裏有一個問題，若是節點同時扮演幾個角色，而這幾個角色之間的Missions 或 Policies 有重疊的部分呢？這時就不能夠在節點褪去一個角色的同時是其全部對應的Missions 和 Policies失效，只能反激活其獨有的部分！

Configurations，很簡單，就是節點初始化時的默認配置。其中含有節點須要載入的全部Modules，節點初始時所扮演與要激活的角色等等。

嗯，根據上述概念，下面總結一下編程工具應該提供什麼樣的功能。

Policies 的編譯工具天然不用多說，必須有，嗯，固然還有對應的語法說明。Missions 與Roles 的編寫應該簡單的多，就是組合和關聯，以及處理一些依賴項，也許不須要發明特有的語言，使用已有的工具就行 ^_^

關於Modules，有些Module 應該是平臺獨有的，好比說有些特殊的傳感器只能用於特定的平臺之上；而有些Module是通用的，這些特殊的限制應當在編寫Module 時就加以說明。加入一個Manifest？？嗯，也許policies也可使用標準XML的形式編寫……可行與否要研究一下！固然，Modules 必須使用Native Programming Language 編寫，即便用C 或是NESCC等等，使用與Linux 驅動程序類似的方式進行編譯應該可行。

最後的最後，相關架構和工做能夠參看Starfish 和 中科院WSN管理論文後面的相關論述，嗯，See you.

參考資料：

[1] Themistoklis Bourdenas, Morris Sloman. Starfish -- Policy driven self-management in wireless sensor networks. 2010 ACM 978-1-60558-971-8/10/05