Skip to content
This repository has been archived by the owner on Aug 25, 2020. It is now read-only.

Release Notes 0.8

Jump to bottom
danbim edited this page Jan 3, 2012 · 20 revisions

The 0.8 release of Testbed Runtime implements some long-awaited features and some requirements of the SmartSantander project. Please see the full list of issues closed here. For a description of the main changes, see below.

Important: the automatic configuration reloading feature introduces changes to the configuration file format that requires testbed providers to update their configuration files. Please check the documentation below!

Changes for Clients (Testbed Users)

Updated Experimentation Scripts

Testbed Runtime 0.8 ships with an updated version of the Experimentation Scripts. Please see Experimentation Scripts 0.8 for details.

Changes for Testbed Providers

Automatic Configuration Reloading

Testbed Runtime's iWSN is now able to reload configuration files at runtime! Originating as a SmartSantander requirement this feature may also come in handy for others. The application core now observes the conf/tr.iwsn-testbed.xml configuration file for changes and acts accordingly, always trying only to start/stop/reload/reconfigure the components that actually changed.

Important: through the introduction of this feature it was necessary to change the semantics of the iWSN configuration file. In the 0.7.2 and earlier versions multiple <application> tags were allowed to have the same name attribute. Starting with 0.8 this name attribute must be unique in the configuration of one host!

So, if you had e.g. two sensor node devices attached and an according configuration like this:

<nodes id="gatewayXX.yourtestbeddomain.org">
  ...
  <applications>
    ...
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x221e</urn>
        <type>telosb</type>
        <usbchipid>XBUNEJDX</usbchipid>
      </ns4:wsnDevice>
    </application>
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x211c</urn>
        <type>isense</type>
      </ns4:wsnDevice>
    </application>
    ...
  </applications>
  ...
</nodes>

You must now make sure to make the name attribute of the <application> tags unique, e.g. by attaching the URN of the node for which the <application> tag is defined:

<nodes id="gatewayXX.yourtestbeddomain.org">
  ...
  <applications>
    ...
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x221e">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x221e</urn>
        <type>telosb</type>
        <usbchipid>XBUNEJDX</usbchipid>
      </ns4:wsnDevice>
    </application>
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x211c">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x211c</urn>
        <type>isense48</type>
      </ns4:wsnDevice>
    </application>
    ...
  </applications>
  ...
</nodes>

The rationale behind this is that Testbed Runtime must be able to tell which part of the configuration file actually changed so that only this part must be reloaded.

Automatic Device Detection and Reconnection

Testbed Runtime is now able to detect sensor node devices being attached and detached and to reconnect to the nodes at runtime. For this feature to work the iWSN configuration file (conf/tr.iwsn-testbed.xml in the assembly) must be updated as follows: Assume you have a gateway host with both an iSense as well as a Telos B device attached. Then the relevant part of the configuration file in 0.7.2 looked as follows:

<nodes id="gatewayXX.yourtestbeddomain.org">
  ...
  <applications>
    ...
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x221e</urn>
        <type>telosb</type>
        <usbchipid>XBUNEJDX</usbchipid>
      </ns4:wsnDevice>
    </application>
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x211c</urn>
        <type>isense</type>
      </ns4:wsnDevice>
    </application>
    ...
  </applications>
  ...
</nodes>

Now, for the 0.8 version to support automatic reconnection to devices you must configure another <application> tag into the configuration file:

<nodes id="gatewayXX.yourtestbeddomain.org">
  ...
  <applications>
    ...
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsndeviceobserver.WSNDeviceObserverFactory" name="WSNDeviceObserver">
      <ns5:wsnDeviceObserver>
        <mapping mac="0x221e" usbchipid="XBUNEJDX"/>
        ...
      </ns5:wsnDeviceObserver>
    </application>
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x221e">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x221e</urn>
        <type>telosb</type>
      </ns4:wsnDevice>
    </application>
    <application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp-urn:wisebed:uzl1:0x211c">
      <ns4:wsnDevice xmlns:ns4="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
        <urn>urn:wisebed:uzl1:0x211c</urn>
        <type>isense48</type>
      </ns4:wsnDevice>
    </application>
    ...
  </applications>
  ...
</nodes>

The WSNDeviceObserver application observes the serial ports of the gateway host and throws events of devices found on which the WSNDeviceApp listens. In order for the WSNDeviceObserver to know the MAC address of a newly attached device it either reads it from the device if supported or it resolves it by looking up the USB chip ID in the <mapping>-tags (Telos B).

Configurable Default Channel Pipeline for Each Device

In the old versions of Testbed Runtime a DLESTXETX-framing decoder was used per default. This framing decoder makes sense with sensor node device operating systems which delimit packets using DLE STX ... DLE ETX bytes. However, other operating systems than iSense OS use different framing algorithms. Therefore, in version before 0.8 testbed client applications had to call the setChannelPipeline() method to configure the de-framing algorithm according to the operating system used in the experiment or to remove data stream preprocessing in the backend altogether.

Testbed Runtime 0.8 now per default doesn't do any preprocessing or de-framing at all. However, it now allows you to set a default channel pipeline for each individual node in iWSNs configuration file (conf/tr.iwsn-testbed.xml in the assembly) if you think it is necessary because, e.g. your iSense sensor node devices are running iSense OS 99% of the time. You can do this by setting a <defaultChannelPipeline>-tag which can either take the name of a configuration file that follows the configuration file format defined by the netty-handlerstack project (see dlestxetx-framing.xml, empty.xml and isense-otap.xml for examples) or by placing the XML contained in these config files directly into the tag:

<application name="WSNDeviceApp-urn:local:0xb2a6" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
  <wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
    <urn>urn:local:0xb2a6</urn>
    <type>isense48</type>
    <defaultChannelPipeline>
      <configurationXml>
        <itm-netty-handlerstack>
          <handler name="dlestxetx-framing" factory="dlestxetx-framing" />
        </itm-netty-handlerstack>
      </configurationXml>
    </defaultChannelPipeline>
  </wsn:wsnDevice>
</application>
<application name="WSNDeviceApp-urn:local:0xb2a7" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
  <wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
    <urn>urn:local:0xb2a7</urn>
    <type>isense48</type>
    <defaultChannelPipeline>
      <configurationFile>empty-channelpipeline.xml</configurationFile>
    </defaultChannelPipeline>
  </wsn:wsnDevice>
</application>

Support for new iSense Core Module 2 (Jennic 5148 CPU)

Although 0.7.2 already supported the iSense Core Module 3 there was no distinction between the old iSense Core Module and the new. In Testbed Runtime 0.8 the Strings isense39 and isense48 can be used to distinguish between them, both in the iWSN configuration file and the WiseML file.

We recently updated the Lübeck testbed by replacing some of the iSense nodes with JN5139R1 CPUs with the new iSense nodes featuring the Jennic 5148 CPU. Please see the testbed site for details.

Support for Passing Arbitrary Configuration Parameters to Device Drivers

Although not currently in use by the drivers for iSense, Telos B and Pacemate, Testbed Runtimes driver interface now allows to pass in arbitrary configuration parameters in Form of a Map<String, String> which will be required for the implementation of Sun SPOT and Waspmote (SmartSantander) drivers. Testbed Runtimes configuration files reflects this by allowing you to specify key/value pairs in the iWSN configuration file (conf/tr.iwsn-testbed.xml in the assembly) like this:

<application name="WSNDeviceApp-urn:local:0xb2a6" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
  <wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
    <urn>urn:local:0xb2a6</urn>
    <type>isense48</type>
    <configuration key="key1" value="value1" />
    <configuration key="key2" value="value2" />
    <configuration key="key3" value="value3" />
  </wsn:wsnDevice>
</application>

The WSNDeviceApp will create a Map<String, String> instance and put the key/value pairs inside. This map will then be passed to the driver interface upon driver instantiation.

Clone this wiki locally