根据主动分布式模型，脚本看起来像是 CS8416-CZZ/CSZ受外部事件影响的状态机，这样的外部事件包括网络消息、传感数据和定时器到期。采用的编程模型是：事件被描述，并和一个事件处理器的定义绑定；根据当前状态，事件处理器将会做出处理并可能创造出一些新的事件和（或）改变当前状态。图7-22就展示了SensorWare的编程模型的一个例子。

                      
    图7-22描述了通过等待命令实现事件。通过命令，程序员能够定义脚本在一个给定的时间中等待时的所有的事件，这些时间包括：受理一个给定格式的消息，或是用给定采样率的传感信息来填充缓存，也可以是等待若干个定时器的时间到期。当任何一个事件在等待命令发生中进行声明时，命令就会终止，返回引起终止的事件。在等待命令下面的代码会处理返回的变量信息并唤醒已挂起的适合此事件的部分代码。在执行挂起事件之后，脚本移动到一个新的等待命令或是等待前命令的循环执行。
    和编程模型同等重要的是支持脚本的运行环境。图7-23描述了环境执行的基本任务。SensorWare将任务划分为固定的和平台相关的，固定任务通常包含在SensorWare的实现中，而平台相关任务依赖于节点平台的具体模块和服务。另外，有可能出现可扩展性和可移植性问题。脚本管理器的任务是接受新的脚本卢生请求，它将请求传递给接入控制任务并接收回复，并启动一个新的线程／任务，为新的脚本运行一个脚本解释器。脚本管理器也在脚本活动期间，保存任意脚本相关的状态，例如脚本数据等。

                
    接入控制和资源使用策略任务负责所有的脚本接入决策，确保脚本在它们的资源限制之内，并且更重要的是检查总的能量消耗。如果整体呈现出巨大的消耗，则按照Sensorware的一定策略选择性的终止一些脚本。
    运行环境还包括资源抽象和资源计量任务，每个任务支持相关的API命令并管理具体的资源，这其中有两个固定的任务，因为每个平台都假设有至少一个“RADIO”任务和一个定时器服务。“RADIO”任务从脚本中接受所要求的网络消息格式的请求，根据需要的脚本接受网络中的信息，并为每个脚本测量无线电利用率。定时器服务通过所有的脚本为定时器接受各种请求，并且为系统提供的嵌入式真实事件计时器服务。从根本上说任务依靠系统提供的单个定时器来提供多个虚拟的定时器。
    即使两个平台具有相同的能力（即同样的模块／服务），它们也依赖于不同的硬件和（或）操作系统，因此SensorWare的代码分为不会改变的（平台独立的代码）和随平台能力变化的（设备定义代码），如图7-24所示。