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