外文翻译译文-TinyOS的接口协议.docVIP

附件1：外文资料翻译译文 TinyOS的接口协议 作者： Will Archer . 计算犹他大学，E-mial地址：warcher@cs.utah.edu。 Philip Levis . 斯坦福大学计算机系pal@cs.stanford.edu。 John Regehr . 计算犹他大学，E-mial地址：regehr@cs.utah.edu。 摘要 TinyOS应用程序然而,其它的重要的好处部件快速开发应用程序的重用能力基本上仍未通过因为在很多情况下接口有隐含的使用限制即可令人沮丧的程序错误的源。 D.2.4 [软件工程]：软件/程序验证——协议规划；D.2.5 [软件工程]：测试和调试测试工具。 一般条款 设计、可靠性、验证 关键词 确认 协议设计 TinyOS 传感器网络 自动化测试 介绍 TinyOS已经是一个成功的基础的中断驱动应用程序。其组件的模式是减少应用代码大小，只用连接在只需要的功能，和提高应用程序开发构件的复用速度。不幸的是，创造可靠的TinyOS应用程序，建造在现有组件，特别是别人写的那些，是非常困难的。一个主要的挑战是，正确的使用TinyOS接口从未经过精心的规定。不能给开发者的想要的自由。 图1一个接口协议执行正确使用nesC介入的界面操作界面之间的用户和供应商 可复用组件的开发人员被迫假定它们的接口会被滥用而需要谨慎编程，增加发展和资源的开销。同样，那些重用已有组件接口被迫承担即使正确使用，访问也可能失败得后果，错误检查和故障恢复策略对上层的发展是很必要的。上述的这些问题，已经被证明是和TinyOS l.x的接口设计中存在的一些相关的问题。这篇论文就是我们检查过得出的结论，我们相信这些问题也会出现在TinyOS 2.0。 为了进一步解决这些问题，我们开发了TinyOS接口协议。图1中所描述的接口协议是一个可检查 图2没有接口协议故障进行隔离(左)，在复杂的TinyOS应用中是很困难的。协议(右)支持通过不断快速、高效的检测检查接口故障。 我们的最终目标是使每个接口都有协议，包括底层的硬件抽象层。当任意的输入都有独立的测试时，就能让单元测试在一个模拟环境中进行。在模拟环境中进行单元测试将发现一些但并非所有的错误；而在充分运行应用中，实际节点也应该能够有效的实施协议。每包几百次传输可能是无误的，但并不是在每个广播的中断字节都可行。 我们的研究主要有两个好处。在短期内, 就像图2所示，作为可测试的协议，那些使开发人员更容易创造错误的可执行文件，和快速定位不正确的程序代码。从长远来看, 我们预计它将可能使用正规的静态方法检查整体和单个不符合其接口协议的应用组件。检查独立的部件是非常艰巨的工作，因为它证明一种特殊的组件在任何可能的实例化中是正确的，而不仅仅是在其中一个。此外，我们希望组件的层面检查来是有用的，在一个假设——确定推理方案[5]，可以归纳的证明一个完整的应用程序是正确的。 TINYOS背景 TinyOS[7]是一款基于组件的操作系统，其组件通过类型化协议相互作用。这个操作系统是用nesC[4] 写的，一种支持组件的C的方言、接口、并发分析、网络类型。建立一个TinyOS应用程序需要将涉及的组件接口连接在一起。接口是双向的，这种接口实际上是提供者组件和使用者组件间的一个多功能交互通道。一方面，接口的提供者实现了接口的一组功能函数，称为命令；另一方面，接口的使用者需要实现的一组功能函数，称为事件。例如，发送信息包是一个命令，而接受信息包是个事件。一般说来，一个接口支持一条狭长而完整的抽象的例如使用一个定时器，发信给一个非稳定性记录，或接收数据包。 图3: 发送信息的接口 图4: 定时器接口 TinyOS不支持阻断。相反，缓慢的操作——特别是那些涉及硬件潜在因素的是分相型SendMsg）。而不是等到操作（SendMsg.send）完成，接口命令就立即返回，允许应用程序继续处理。当操作都完成,接口表示完成的事件（SendMsg.sendDone)，在此情况下该用户可以回收包缓冲区。分相式语法具有许多优势，但这对于那些被迫明确地维持多重的组件技术的开发商而言也造成了困难。分相式操作是我们所发现的相当多的误用的接口来源。 一个执行否则无法声明另一个组件：组件交互作用仅通过接口。这明确的分离可以让程序员容易改变已经被使用的实现。例如，一个组件名叫“AppM”使用”SendMsg”可直接连接到一个单极性的通信堆栈, 一个多极性混合堆栈，或一发送队列，而没有改变AppM的代码。 能够轻易转换不同接口的实现方式要求实现是可互换的。不幸的是，目前，大多数接口并没有准确语义标准和驱动的模式。因为有一个很好的协议的实施范围，一个组件必须能承受广泛范围的行为。这导致冗余的代码，所以必须编程保护每个组件。 设计协议制度 这