]> oss.titaniummirror.com Git - tinyos-2.x.git/blobdiff - doc/html/tep130.html
fixed html validation error in docs
[tinyos-2.x.git] / doc / html / tep130.html
diff --git a/doc/html/tep130.html b/doc/html/tep130.html
new file mode 100644 (file)
index 0000000..c10f592
--- /dev/null
@@ -0,0 +1,471 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+<title>Testbeds - Setup and Interfaces</title>
+<meta name="author" content="Jan Beutel" />
+<style type="text/css">
+
+/*
+:Author: David Goodger
+:Contact: goodger@users.sourceforge.net
+:date: $Date$
+:version: $Revision$
+:copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the HTML output of Docutils.
+*/
+body {
+  font-family: Times;
+  font-size: 16px;
+}
+
+.first {
+  margin-top: 0 ! important }
+
+.last {
+  margin-bottom: 0 ! important }
+
+.hidden {
+  display: none }
+
+a.toc-backref {
+  text-decoration: none ;
+  color: black }
+
+blockquote.epigraph {
+  margin: 2em 5em ; }
+
+dd {
+  margin-bottom: 0.5em }
+
+div.abstract {
+  margin: 2em 5em }
+
+div.abstract p.topic-title {
+  font-weight: bold ;
+  text-align: center }
+
+div.attention, div.caution, div.danger, div.error, div.hint,
+div.important, div.note, div.tip, div.warning, div.admonition {
+  margin: 2em ;
+  border: medium outset ;
+  padding: 1em }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title {
+  color: red ;
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.hint p.admonition-title, div.important p.admonition-title,
+div.note p.admonition-title, div.tip p.admonition-title,
+div.admonition p.admonition-title {
+  font-weight: bold ;
+  font-family: sans-serif }
+
+div.dedication {
+  margin: 2em 5em ;
+  text-align: center ;
+  font-style: italic }
+
+div.dedication p.topic-title {
+  font-weight: bold ;
+  font-style: normal }
+
+div.figure {
+  margin-left: 2em }
+
+div.footer, div.header {
+  font-size: smaller }
+
+div.line-block {
+  display: block ;
+  margin-top: 1em ;
+  margin-bottom: 1em }
+
+div.line-block div.line-block {
+  margin-top: 0 ;
+  margin-bottom: 0 ;
+  margin-left: 1.5em }
+
+div.sidebar {
+  margin-left: 1em ;
+  border: medium outset ;
+  padding: 0em 1em ;
+  background-color: #ffffee ;
+  width: 40% ;
+  float: right ;
+  clear: right }
+
+div.sidebar p.rubric {
+  font-family: sans-serif ;
+  font-size: medium }
+
+div.system-messages {
+  margin: 5em }
+
+div.system-messages h1 {
+  color: red }
+
+div.system-message {
+  border: medium outset ;
+  padding: 1em }
+
+div.system-message p.system-message-title {
+  color: red ;
+  font-weight: bold }
+
+div.topic {
+  margin: 2em }
+
+h1 {
+  font-family: Arial, sans-serif;
+  font-size: 20px;
+}
+
+h1.title {
+ text-align: center;
+ font-size: 32px;
+}
+
+h2 {
+ font-size: 16px;
+ font-family: Arial, sans-serif;
+}
+
+h2.subtitle {
+  text-align: center }
+
+h3 {
+ font-size: 12px;
+ font-family: Arial, sans-serif;
+}
+
+hr {
+  width: 75% }
+
+ol.simple, ul.simple {
+  margin-bottom: 1em }
+
+ol.arabic {
+  list-style: decimal }
+
+ol.loweralpha {
+  list-style: lower-alpha }
+
+ol.upperalpha {
+  list-style: upper-alpha }
+
+ol.lowerroman {
+  list-style: lower-roman }
+
+ol.upperroman {
+  list-style: upper-roman }
+
+p.attribution {
+  text-align: right ;
+  margin-left: 50% }
+
+p.caption {
+  font-style: italic }
+
+p.credits {
+  font-style: italic ;
+  font-size: smaller }
+
+p.label {
+  white-space: nowrap }
+
+p.rubric {
+  font-weight: bold ;
+  font-size: larger ;
+  color: maroon ;
+  text-align: center }
+
+p.sidebar-title {
+  font-family: sans-serif ;
+  font-weight: bold ;
+  font-size: larger }
+
+p.sidebar-subtitle {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+p.topic-title {
+  font-weight: bold }
+
+pre.address {
+  margin-bottom: 0 ;
+  margin-top: 0 ;
+  font-family: serif ;
+  font-size: 100% }
+
+pre.line-block {
+  font-family: serif ;
+  font-size: 100% }
+
+pre.literal-block, pre.doctest-block {
+  margin-left: 2em ;
+  margin-right: 2em ;
+  background-color: #eeeeee;
+  border-color: #000000;
+  border-width: thin; 
+  font-size: 14px
+}
+
+span.classifier {
+  font-family: sans-serif ;
+  font-style: oblique }
+
+span.classifier-delimiter {
+  font-family: sans-serif ;
+  font-weight: bold }
+
+span.interpreted {
+  font-family: sans-serif }
+
+span.option {
+  white-space: nowrap }
+
+span.option-argument {
+  font-style: italic }
+
+span.pre {
+  white-space: pre }
+
+span.problematic {
+  color: red }
+
+table {
+  margin-top: 0.5em ;
+  margin-bottom: 0.5em }
+
+table.citation {
+  border-left: solid thin gray ;
+  padding-left: 0.5ex }
+
+table.docinfo {
+  margin: 2em 4em;
+}
+
+table.footnote {
+  border-left: solid thin black ;
+  padding-left: 0.5ex }
+
+td, th {
+  padding-left: 0.5em ;
+  padding-right: 0.5em ;
+  vertical-align: top }
+
+th.docinfo-name, th.field-name {
+  font-weight: bold ;
+  text-align: left ;
+  white-space: nowrap;
+  }
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+  font-size: 100% }
+
+tt {}
+
+ul.auto-toc {
+  list-style-type: none }
+
+</style>
+</head>
+<body>
+<div class="document" id="testbeds-setup-and-interfaces">
+<h1 class="title">Testbeds - Setup and Interfaces</h1>
+<table class="docinfo" frame="void" rules="none">
+<col class="docinfo-name" />
+<col class="docinfo-content" />
+<tbody valign="top">
+<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">130</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Testbeds Working Group</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
+</tr>
+<tr><th class="docinfo-name">Status:</th>
+<td>Draft</td></tr>
+<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
+</tr>
+<tr><th class="docinfo-name">Author:</th>
+<td>Jan Beutel</td></tr>
+<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">14-Jun-2007</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.2</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-06-28</td>
+</tr>
+<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Testbed WG &lt;<a class="reference" href="mailto:tinyos-testbed-wg&#64;eecs.harvard.edu">tinyos-testbed-wg&#64;eecs.harvard.edu</a>&gt;&gt;</td>
+</tr>
+</tbody>
+</table>
+<div class="note">
+<p class="first admonition-title">Note</p>
+<p class="last">This document specifies a Best Current Practices for the
+TinyOS Community, and requests discussion and suggestions for
+improvements.  Distribution of this memo is unlimited.</p>
+</div>
+<div class="section">
+<h1><a id="abstract" name="abstract">Abstract</a></h1>
+<p>This memo describes the structure and interfaces required for TinyOS compliant
+testbeds.</p>
+</div>
+<div class="section">
+<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
+<p>The testing and validation of embedded code on real hardware is key to
+successful development of TinyOS applications. Although popular and powerful for
+high level analysis, current simulation methods lack in terms of level of
+detail and accuracy when used accross multiple system layers where abstractions
+and models used are inherently imperfect and impair results. Methods such as
+hardware emulation commonly used in embedded system development allow the
+execution of code on a hardware platform and therefore can guarantee timing but
+are very limited in terms of scalability and often confined to a lab usage only.</p>
+<p>Sensor network testbeds try to overcome these deficiencies by allowing to execute
+software code under realistic operating conditions on real hardware embedded in
+a target environment. This approach allows to generate a level of detail especially
+in respect to the whole system (radio. processor, storage, sensors, interfaces)
+and the wireless environment (noise, fading, shading, errors, failures) while
+maintaining a certain degree of scalability. Remote programming as well as a
+feedback of status and debugging information from the nodes using testbed
+infrastructure alleviates the need for integrated services in sensor network
+applications. Additionally testbeds allow to operate a set of nodes in a
+controlled environment, i.e. using temperature variations or a controlled
+wireless environment.</p>
+<p>A typical testbed is made up of a number of nodes (?do we state amounts here?)
+connected to a central resource for control and logging that are deployed in a
+physical space (testing area). Typically the central resource is a server with
+integrated datalogging capability. Often a web front end serves as a simple control and
+visualization resource. For the submission of testing jobs and the analysis of
+testing results external tools are attached to the central resource using a
+standardized interface. This document serves as a key specification document for
+such an interface and its intended usage.</p>
+<p>MISSING: Difference of a testbed vs. a desktop test (e.g. single nodes with a
+programmer or a simple usb grid)</p>
+<p>Examples of currently used sensor network testbeds are MoteLab [<a class="reference" href="#id1">1</a>] and the
+Deployment-Support Network [<a class="reference" href="#id2">2</a>].</p>
+</div>
+<div class="section">
+<h1><a id="testbed-usage" name="testbed-usage">2. Testbed Usage</a></h1>
+<p>A testbed can serve different purposes depending on the development status and
+requirements of a specific project. While this document does not target to restrict
+such usage it defines a set of mandatory modes of operation that a testbed must
+be able to support:</p>
+<p>Modes of Operation:</p>
+<ul class="simple">
+<li>Single Shot Operation</li>
+</ul>
+<p>Execute a testing job consisting of an uploading of a specific code image onto a
+set of nodes, remote programming of nodes using a testbed resource, the
+synchronized start of this software, capture of resulting target response, the
+centralized storage and timestamping of all actions and target response, ending
+of test execution, notification of a user of the end of test execution, output
+of all stored data on demand.</p>
+<ul class="simple">
+<li>Repetitive (e.g. using continuous integration or for regression testing)</li>
+</ul>
+<p>A concatenation of single shot testing jobs, that in practice often will be used
+with the variation of one or more parameters.</p>
+<ul class="simple">
+<li>Long Term Operation (Profiling)</li>
+</ul>
+<p>Other Topics:</p>
+<ul class="simple">
+<li>Federated Testbeds (in multiple environments)</li>
+<li>Access/Resource Arbitration</li>
+<li>Scheduling of testing jobs</li>
+</ul>
+</div>
+<div class="section">
+<h1><a id="testbed-services" name="testbed-services">3. Testbed Services</a></h1>
+<p>Required Services:</p>
+<ul class="simple">
+<li>identification of target devices (presence, type, hw rev)</li>
+<li>programming of target devices</li>
+<li>resetting of target devices</li>
+<li>logging of target response (UART mandatory, IRQ optional)</li>
+<li>versioning/identification of uploaded software</li>
+<li>identification/versioning/archiving of testing jobs</li>
+<li>testbed status information</li>
+<li>identification of testbed services</li>
+<li>user authentification</li>
+</ul>
+<p>Optional:
+- power measurements
+- stimuli
+- distributed scheduling of actions (at nodes)</p>
+</div>
+<div class="section">
+<h1><a id="implementation" name="implementation">4. Implementation</a></h1>
+<ul class="simple">
+<li>Server, DB/Storage, Interface XMLRPC</li>
+<li>Connection fabric</li>
+<li>On- and offline logging</li>
+<li>Supplied Power</li>
+<li>Mote Hardware</li>
+</ul>
+<p>THINGS TO DISCUSS</p>
+<ul class="simple">
+<li>?Do we state minimum requirements?</li>
+<li>number of nodes</li>
+<li>power supply (fixed/batt)</li>
+<li>power profiling</li>
+<li>power on/off of targets? is simple reset/erasing enough?</li>
+<li>feedback channel capabilities (delay, errors, lost packets...)</li>
+<li>target control? is control of (writing to) targets required or is it an optional feature?</li>
+<li>scheduling of actions (time synched???)</li>
+</ul>
+</div>
+<div class="section">
+<h1><a id="reference" name="reference">5. Reference</a></h1>
+</div>
+<div class="section">
+<h1><a id="acknowledgments" name="acknowledgments">6. Acknowledgments</a></h1>
+</div>
+<div class="section">
+<h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
+<div class="line-block">
+<div class="line">Jan Beutel</div>
+<div class="line">Gloriastr 35</div>
+<div class="line">ETH Zurich</div>
+<div class="line">8092 Zurich</div>
+<div class="line">Switzerland</div>
+<div class="line"><br /></div>
+<div class="line">phone - +41 44 632 7032</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:j.beutel&#64;ieee.org">j.beutel&#64;ieee.org</a></div>
+</div>
+</div>
+<div class="section">
+<h1><a id="citations" name="citations">8. Citations</a></h1>
+<table class="docutils footnote" frame="void" id="id1" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id1">[1]</a></td><td>G. Werner-Allen, P. Swieskowski, and M. Welsh. MoteLab: A wireless sensor
+network testbed. In Proc. 4th Int'l Conf. Information Processing Sensor
+Networks (IPSN '05), pages 483-488. IEEE, Piscataway, NJ, April 2005.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id2" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a name="id2">[2]</a></td><td>M. Dyer, J. Beutel, L. Thiele, T. Kalt, P. Oehen, K. Martin, and P. Blum.
+Deployment support network - a toolkit for the development of WSNs. In Proc.
+4th European Workshop on Sensor Networks (EWSN 2007), volume 4373 of Lecture
+Notes in Computer Science, pages 195-211. Springer, Berlin, January 2007.</td></tr>
+</tbody>
+</table>
+</div>
+<div class="section">
+<h1><a id="appendix-a-example-appendix" name="appendix-a-example-appendix">Appendix A. Example Appendix</a></h1>
+<p>This is an example appendix. Appendices begin with the letter A.</p>
+</div>
+</div>
+</body>
+</html>