一种面向无线传感网络的构件化开发方法

　　摘要：构件化的开发模式使开发者在开发过程中能充分调用构件库中现有的构件为其服务。研究了构件化开发模式的方法和特点，针对目前无线传感器网络协议开发方法中的缺陷，提出一种由应用层构件直接调用底层构件的直接调用法。用该方法分析实现了无线传感器网络中主流的IEEE802.15.4 标准，通过系统实现后的测试证明，该方案具有更高的开发效率和代码执行效率。

引言

　　随着移动技术和互联网技术的飞速发展，移动网络将是下一代网络发展的大趋势。而移动网络的重要子网之一无线传感器网络能够大大扩展互联网的触角。由于无线传感器网络低功耗、低成本、分布式和资源有限等特点，使得开发无线传感器网络的相关协议成为无线传感器网络发展的关键技术因素之一。传统的软件开发方法显然已经不适合无线传感器协议的开发，而近来兴起的新的开发模式是基于构件化的软件开发方法。

　　基于构件化的软件开发(CBSD,comp onent-based software development)方法是一种可以提供软件复用性的开发方法。构件是用于进行软件开发、复用和软件组装的基本单元。在面向构件的技术里，一个应用软件不是通过大量的代码来描述，而是通过数量有限的构件来描述，如图1(a)所示。与传统的嵌入式软件不同，构件化的嵌入式软件是由一组软件构件构成的，这些构件的一个或者几个组合成一个完整的应用；而且新的应用也可以使用已有构件，从而提高软件复用性。传统模式下开发出来的嵌入式软件提供的是专用服务，软件与应用是一一对应的，如图1(b)所示。整个过程中代码量大，复杂度高，代码重用性小，并且更新困难，不适应无线传感器节点资源有限的要求。

　　TinyOS是一种基于构件化的无线传感器网络操作系统，该系统本身就是一个构件库。其开发语言nesC 提供了对软件构件技术的支持。通过灵活组装各个固定功能的芯片级构件可以方便地搭建起不同硬件平台级构件。因此在TinyOS 系统下开发构件化的无线传感器协议的方法已被广泛使用。但是，目前由于开发者过度依靠现有的集成构件，导致开发出来协议性能并不理想。

图1 构件化的嵌入式软件与传统嵌入式软件

1 现有开发方法描述

　　系统为了简化开发者的开发难度，对各芯片的底层构件进行了构件化包装。调用硬件底层构件所提供的最基本功能接口，来组合实现一些功能模块，如配制芯片模块、发送数据模块、接收数据模块等。系统对各芯片的硬件抽象层的集成化操作基本是一样的，图2 是CC2420系统集成构件调用硬件抽象层构件的关系。

图2 系统集成构件和硬件抽象层构件关系

　　由图2 可以看出，系统集成构件起到一个桥梁作用，使开发者简化了开发工作。但是，系统集成构件在调用硬件抽象构件实现自身功能的时候出现重复调用问题。并且构件CC2420SpiC 在不同的层(系统集成层和硬件抽象层)都有使用，这本身使得系统集成层和物

　　理抽象层关系变得模糊和复杂，加大开发者开发难度。

　　根据构件化系统编程可知，调用构件的接口需要实现提供接口构件中的event 事件。如果多个构件重复使用同一个构件的同一个接口，每个使用该接口的构件都需要将该接口中的event 事件执行一次。系统集成构件同时调用相同的硬件抽象层构件中的接口命令时，完成命令的signal 事件会通知每个使用该接口的构件。这就导致了构件化系统下编程常见问题：扇出(fan-out)。系统为了解决这一问题不得不将构件性质改为generic 类型。而这会引入新的构件调用模式。所有这些使得系统集成构件对硬件抽象层构件的调用变得比实际要复杂，代码的执行效率大大降低。

2 直接调用底层构件方法描述

　　对系统集成构件的研究发现，应用层构件在调用系统集成构件时最终调用了硬件抽象层构件，只是系统集成构件将硬件抽象层构件重新整合到某个大的集成构件中，方便用户查找接口。实际上，由于嵌入式软件和硬件结合性高、硬件资源有限等特点，为了使得软件系统性能达到最高，嵌入式软件开发者在开发之前对硬件已经非常熟悉。在这种情况下没有必要在硬件抽象层之上硬性加上系统抽象层。对开发者而言，直接调用底层硬件抽象层构件会更直观、简单。

　　具体实现方法如图3 所示，在构件操作上对没有引入新功能的构件在配线构件配线时候可以跨过整个系统集成构件，而不会影响系统功能，并可以简化开发过程，提高运行效率。以下将这一方法简称为直接调用法。

图3 构件简化过程

　　[page]

      图3 中构件1 和构件2 不是提供最底层功能的构件，它们将底层构件3、构件4 和构件5 进行重新整合，最终使用的是构件3、构件4 和构件5 的功能。所以，通过改进后的方案中，让应用构件直接调用构件3、构件4 和构件5，让构件1 和构件2 的功能交给应用构件去完成，这样提高了代码的执行效率和开发效率。实际上，结合构件化系统可知，图3 的简化过程解决了扇出问题，应用构件只要调用了一个硬件抽象层构件，就可以在应用构件内任何需要的地方去调用硬件抽象构件所提供的接口中命令。配线构件在配线时也变的简单，没有系统集成构件中多个硬件抽象层构件的重复配线操作。

　　对构件化系统以及底层硬件抽象构件和各具体芯片研究分析可知，系统集成构件都是起到上述作用，同时又引入新的问题。若开发人员对硬件抽象构件熟悉，就完全可以跨过系统集成构件而直接使用硬件抽象层提供的构件。这样就简化了原方案中系统集成构件之间繁杂的调用关系，更重要的是可以大大提高系统的运行效率，还以CC2420 系统集成构件为例，其改进后的构件调用方案如图4 所示：

图4 改进方案中构件间关系

　　由图4 可知，原来方案中的系统集成级构件层的构件没有被调用，而直接调用硬件抽象层构件。由图4 与图2 对比发现，将原来系统集成层构件*能移到PhyP 构件中完成，这样避免了对底层构件的重复使用，整个结构更清晰简单。因此，需要对PhyP 构件做改进，使得其能够完成初始化射频芯片，调用射频芯片发送和接受数据。虽然看起来PhyP 构件要比实际代码量大，但是对改进后系统运行的测试结果表明，提高了10%的工作效率，缩减3000 行的代码量。

3 测试直接调用法

　　将直接调用法应用IEEE802.15.4 的设计与实现。IEEE802.15.4 标准目前已成为事实上的无线传感器标准，并在各自硬件平台上开发该协议。以IEEE802.15.4 标准为例，在TinyOS系统、CC2420 射频芯片的环境下使用本文直接调用法来设计实现该标准，并测试其工作性能。

　　设计按照TinyOS 系统的构件化编程思路进行。物理层将设计两个构件(PhyP，PhyC)，相关操作通过标准中定义的两个接口进行：数据访问接口(PD)、管理接口(PLME)。构件PhyP 是物理层的主要实现构件，它具有初始化构件、发送数据、接受数据三个基本功能。MAC 层设计两个构件：MacC、MacP，其中MacP 是主要的执行构件。MAC 层中有两种设备：协调器节点和非协调器节点。协调器节点负责建立网络：确立网络号(PANID)、本节点的短地址、并产生信标帧载荷部分。非协调器节点加入协调器节点所建立的网络中组成更大的个人区域网络。

　　3.1 功能测试

　　测试程序运行在两个对等的节点上，分两个阶段测试。首先测试物理层的通信情况：一号个节点产生一个有效载荷为：0 至9 十个数据的数据包并发送给另外二号节点，二号节点在收到上述数据包后原封不动将该数据包又发回给刚才发送者。发送和接收到的数据包的内容是一致的，并且信号灯闪烁正常，说明节点之间的通信正常，物理层设计工作正常。进一步测试MAC 层工作情况：将一号节点设为协调器节点，二号节点设置为非协调器节点。一号节点初始化并建立一个PAN 网，二号节点请求加入一号节点所创建的网中，验证网络是否工作正常。通过功能测试可知，整个工作过程是按照IEEE802.15.4 标准的规定运行，实现了该标准功能。

　　3.2 效率测试

　　工作效率测试中应用产生50 个数据包后调用MAC 层发送接口发送这50 个数据包，从应用调用MAC 层数据接口时开始计时，到应用层收到包成功发送的确认消息为止。记录下这个响应时间，并依次增大发送数据包的的有效载荷，从10 个字节增加到90，记录下有效载和增加时的响应时间。效率测试将分别在原始方案和直接调用法开发出来的协议中进行，统计两种不同方法的工作参数，最后得到的时间分布如图5 所示。

图5 收发数据效率比较

　　由图5 可知，在50 个数据包的情况下，当数据包的有效载荷在10 至50 个字节时二者响应时间差距并不大，响应时间提高了10%左右，当有效载荷增加到50 个字节以上时，响应时间提高30%，有利于满足嵌入式系统的实时性要求

结束语

　　本方案通过分析无线传感器网络现有的开发方法的不足，提出直接调用法，并用该方法实现IEEE802.15.4 标准，最终达到预期目标。方案的移植性高，稳定性好，代码量小，适合无线传感器资源有限，实时性要求高的特点。同时直接调用法可以用来开发其他通信协议，如：802.11、LEACH、蓝牙等。